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

[Fangrui Song via llvm-commits]

MaskRay 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 creating the undefined symbols via `addSymbol(Undefined{...})` (unless there's a non-bitcode archive member to keep working around the libgcc issue)?

I think it's related to an implementation detail of lld and other linkers, but more related to the LTO symbol resolution scheme. The IR symbol table should strive to provide a full picture. In this case, it knows the architecture and the code model and can make a best guess of whether `_GLOBAL_OFFSET_TABLE_` will be needed.

> > 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.

I hope that the linker only defines `_GLOBAL_OFFSET_TABLE_` when it is really used.
At the `LTO::getRuntimeLibcallSymbols()` call site there is no information about code models to make a good decision.

The IRSymTab code will likely be extended to be smarter on function-local inline asm symbols (beside current model-level inline asm symbols).
Adding `_GLOBAL_OFFSET_TABLE_` there feel natural to me.


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