Useless .got.plt section being created with `-mcmodel=large` and `-flto`, absent with either removed

[CasualPokePlayer]

Functionally, this bug doesn't really cause any issue, other than raising a "false red flag" for a project which relies on there being absolutely no relocations occurring.

For context, I work with a project which requires that the end build have no reloations, as the "ld.so" used (if you can call it that) does not support relocations. As such, .got.plt sections appearing is a red flag potentially indicating something is wrong with the builds.

This setup isn't needed to reproduce the issue anyways, as it appears to be some problem caused by a combination of -mcmodel=large and -flto. A simple test.c file can be used to see this issue:

void _start(void) {}

This will show a .got.plt section being created:
clang-20 -mcmodel=large -nostdlib -flto -c ./test.c -o test.o ; clang-20 -nostdlib -fuse-ld=lld-20 ./test.o ; objdump -s --section=.got.plt ./a.out
This omits -mcmodel=large and thus will not create the section (and show it is not being created):
clang-20 -nostdlib -flto -c ./test.c -o test.o ; clang-20 -nostdlib -fuse-ld=lld-20 ./test.o ; objdump -s --section=.got.plt ./a.out
This omits -flto and this will also not create the section (and show it is not being created):
clang-20 -mcmodel=large -nostdlib -c ./test.c -o test.o ; clang-20 -nostdlib -fuse-ld=lld-20 ./test.o ; objdump -s --section=.got.plt ./a.out

This is being done on clang 20.1.8 on Debian 11, fetched from llvm's apt repository. This issue did not occur on clang 18.1.8.

[brad0]

cc @MaskRay

[MaskRay]

LTO-compiled relocatable files for x86-64 (medium or large code model) and x86-32 may reference _GLOBAL_OFFSET_TABLE_.
If the linker does not define this symbol, it will trigger an "undefined symbol" error.
To address this, the IR symbol table synthesizes a _GLOBAL_OFFSET_TABLE_ reference.
The linker then defines _GLOBAL_OFFSET_TABLE_ relative to the .got.plt section.
A LTO-compiled relocatable file that does not reference _GLOBAL_OFFSET_TABLE_ and has no relocations relative to .got.plt will result in an empty and unused .got.plt.

Eliminating the empty .got.plt section for the LTO x86-64 medium/large scenario would require complex changes in both lld/ELF, which I don't believe is a worthwhile effort. Therefore, this issue is considered a "wontfix".

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: None (CasualPokePlayer)

Functionally, this bug doesn't really cause any issue, other than raising a "false red flag" for a project which relies on there being absolutely no relocations occurring.

For context, I work with a project which requires that the end build have no reloations, as the "ld.so" used (if you can call it that) does not support relocations. As such, .got.plt sections appearing is a red flag potentially indicating something is wrong with the builds.

This setup isn't needed to reproduce the issue anyways, as it appears to be some problem caused by a combination of -mcmodel=large and -flto. A simple test.c file can be used to see this issue:

void _start(void) {}

This will show a .got.plt section being created:
clang-20 -mcmodel=large -nostdlib -flto -c ./test.c -o test.o ; clang-20 -nostdlib -fuse-ld=lld-20 ./test.o ; objdump -s --section=.got.plt ./a.out
This omits -mcmodel=large and thus will not create the section (and show it is not being created):
clang-20 -nostdlib -flto -c ./test.c -o test.o ; clang-20 -nostdlib -fuse-ld=lld-20 ./test.o ; objdump -s --section=.got.plt ./a.out
This omits -flto and this will also not create the section (and show it is not being created):
clang-20 -mcmodel=large -nostdlib -c ./test.c -o test.o ; clang-20 -nostdlib -fuse-ld=lld-20 ./test.o ; objdump -s --section=.got.plt ./a.out

This is being done on clang 20.1.8 on Debian 11, fetched from llvm's apt repository. This issue did not occur on clang 18.1.8.