Using bitcode files in contexts where one normally uses an object file is a bit odd.

For example, during symbol resolution part of a linker, the linker can look at just the symbol table of the object file and the names it looks up can be StringRefs pointing to the underlying mmap.

The situation is very different with bitcode files

* The names are stored in a bitcode record and we have to parse quite a bit to make them available.
* The names are compressed (char6), so one cannot just point a StringRef at them.
* Given the mentioned complexity, it we would have to duplicate quite a bit of code to read the names, so everyone just builds a Module.
* The names are not final in some case. For example, in MachO they are missing a leading _ and so have to be passed to the Mangler before the linker can use them in symbol resolution.
* Symbol names from inline assembly are not included anywhere. One has to parse the assembly to get them.

This creates amusing issues like lib/Object depending on MC and llvm-nm depending on Target.

I think the solution to these problem is to add a blob with a symbol table to the bitcode file. The table would
* Include the *final* name symbols (_foo, not foo).
* Not be compressed so that be can drop the IRObjectFile and still keep StringRef.
* Be easy to parse without a LLVMContext.
* Include names created by inline assembly.
* Include other information a linker or nm would want: linkage, visbility, comdat