This is actually a bit too broad and will result in issues with intrinsics.
That will be addressed in the next patch.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Without this patch, llvm.global_ctors is not added to the combined module and so the final output contains no ctors. Programs that need these are thus mis-linked/mis-compiled.
The need for ExtraKeeps is because llvm.global_ctors and the other SF_FormatSpecific have names in IR but those names are not symbols for the linker.
ELF/InputFiles.cpp | ||
---|---|---|
454 ↗ | (On Diff #50198) | Do you need to copy strings? Because Symtab has unique_ptrs to BitcodeFiles, they are not freed until the program ends. |
ELF/InputFiles.cpp | ||
---|---|---|
454 ↗ | (On Diff #50198) | Yes. M goes away at the end of this function. |
LGTM with a nit.
ELF/InputFiles.h | ||
---|---|---|
192 ↗ | (On Diff #50198) | Add a comment for this member (for those like me who don't know why we need this.) |
@rafael, could you comment on the high level design here? I think this is fairly reasonable but as with the other patches I think you may have a specific idea of the "right" way to do things.
So, the horrible special case is appending linkage. Long term we should delete it. For now you can check just for it instead of all SF_FormatSpecific.
The other issue is how we propagate information on which symbols are needed. Currently we create SymbolBodies. There are a few problem with that
- As you point out, we don't want to create them for appending linkage.
- It requires doing a hash lookup to get the GV on the other side.
There are two possible solutions that fix both issues
- Use a single LLVMContext and keep the modules alive.
- Create a IRObjectFile again addBitcodeFile instead of using getLazyBitcodeModule. That would let us match GV and SymbolBody by the index instead of name.