[lld] [llvm] IRSymTab: Record _GLOBAL_OFFSET_TABLE_ for ELF x86 (PR #89463)

[Arthur Eubanks via llvm-commits]

aeubanks wrote:

ah, so you're saying that LTO bitcode files should be more like a normal object file and declare everything in their symbol table up front before actually creating object files. this is so that we can follow ELF linking logic to determine which subset of LTO bitcode files we want to link (after LTO-ing them and creating an object file)? I was missing the part where we performed normal ELF linking logic on bitcode files as well. although linker-created symbols don't really participate in this the same way normal symbols do...

it still seems a weird to me that we can't move the call to `addReservedSymbols()` after `compileBitcodeFiles<ELFT>(skipLinkedOutput)` and that we have to force all input bitcode to declare dependencies on any potentially created linker-defined symbols. this forces LTO (which is supposed to be middle-end-y) to know about codegen details which isn't super nice.

I think this is a similar but reversed argument to your argument about the linker needing to know about runtime library calls, which I agree ideally would be in LTO bitcode files. the difference is that for runtime library calls, adding all potentially created runtime calls to the bitcode symbol table is expensive. but changing the order in which we call `addReservedSymbols()` and `compileBitcodeFiles` seems doable(?)

thoughts?

https://github.com/llvm/llvm-project/pull/89463