[llvm-bugs] [Bug 27551] New: Bitcode files should have a symbol table similar to object files

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27551

            Bug ID: 27551
           Summary: Bitcode files should have a symbol table similar to
                    object files
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Bitcode Writer
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvm-bugs at lists.llvm.org, mehdi.amini at apple.com
    Classification: Unclassified

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160428/17903640/attachment-0001.html>