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: unassignedb...@nondot.org
Reporter: rafael.espind...@gmail.com
CC: llvm-bugs@lists.llvm.org, mehdi.am...@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
