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

[via llvm-commits]

pcc wrote:

> That mechanism and `LTO::getRuntimeLibcallSymbols()` handle lazy symbols that appear in the symbol table before LTO compilation. `_GLOBAL_OFFSET_TABLE_` is a special case that it may not be in the symbol table when LTO compilation occurs.

Isn't that just an implementation detail of lld? Basically, the behavior of `handleLibcall` should be as if we loaded an object file with an undefined symbol with that name. Currently we only implement the archive loading aspect of that behavior and only if the target is a bitcode file as a workaround for the libgcc issue, but maybe what we should really be doing is actually defining the symbols via `addSymbol` (unless there's a non-bitcode archive member to keep working around the libgcc issue)?

> Technically linkers can add the special case to `handleLibcall` by ensuring `_GLOBAL_OFFSET_TABLE_` is always present (thigh might only be needed for x86). Personally I feel that LLVMLTO, which is equipped with more information, is the best place to implement this to benefit all linkers (GNU ld might always define `_GLOBAL_OFFSET_TABLE_` when dynamic sections are needed).

Right, LTO (on behalf of the LLVM backend) should be the source of truth of this information, and it can be accessed via `LTO::getRuntimeLibcallSymbols()`. It doesn't follow that this information needs to be in every bitcode symbol table.

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