lld doesn't support x86-32 -fno-plt GD->LD, GD->LE, LD->LE optimizations #59769
Comments
|
Perhaps I should mention just skipping the |
|
FYI the downstream issue is: https://gitlab.alpinelinux.org/alpine/aports/-/issues/14395 |
rakslice
changed the title
|
Your build uses I can add the support to lld x86-32. The x86-64 port does support GOTPCRELX |
the above build is with clang, no? (
i had added it to shave a subpercent off binary size- i didn't think it was actually broken on 32-bit x86. fooled myself again :) |
|
Looks good. The new output for this example is The resulting binary works. |
|
@llvm/issue-subscribers-lld-elf |
MaskRay
changed the title
OK, I actually added -fno-plt for
|
For x86-32, {clang,gcc} -fno-plt uses `call *___tls_get_addr@GOT(%reg)` instead
of `call ___tls_get_addr@PLT`. GD to IE/LE relaxations need to shift the offset
by one while LD to LE relaxation needs to use a different code sequence.
While here, fix some comments.
Fix llvm/llvm-project#59769
Differential Revision: https://reviews.llvm.org/D140813
I'm in the process of chasing the segfault in firefox in alpine 3.17 x86.
I've found that an object file
mozglue/baseprofiler/Unified_cpp_mozglue_baseprofiler0.obuilt withclang++(build command line)
has TLS
lea-callsequences likewith relevant relocs
when this is linked with
lld(build command line)
(resulting
lldcommand line)it generates broken output like
this
mov-nop-lea-no-op is the canned sequence fromX86::relaxTlsLdToLe()inlld/ELF/Arch/X86.cpphttps://github.com/llvm/llvm-project/blob/llvmorg-15.0.6/lld/ELF/Arch/X86.cpp#L462,which is basically the LD->LE transition right out of "ELF Handling for Thread-Local Storage" v0.21 (2013-08-22) starting on p.54 (https://lrita.github.io/images/posts/cplusplus/ELF_Handling_For_Thread-Local_Storage.pdf#page=54), edit: actually it's the second one, "The GNU variant" on the next page.
But that particular rewrite is clearly inappropriate; the
callhere in the GOT___tls_get_addrcase is 6 bytes rather than presumably 5 the canned sequence is expecting so it is a byte short, and leaves us with garbage output.How
lldgot to this:lld/ELF/Arch/X86.cpp:92: useexprR_TLSLD_GOTPLTforR_386_TLS_LDMhttps://github.com/llvm/llvm-project/blob/llvmorg-15.0.6/lld/ELF/Arch/X86.cpp#L92
lld/ELF/Relocations.cpp:1218: handling of theR_TLSLD_GOTPLTrelocation figures that this LD->LE "relaxation" applies https://github.com/llvm/llvm-project/blob/llvmorg-15.0.6/lld/ELF/Relocations.cpp#L1218lld/ELF/Arch/X86.cpp:462: as notedX86::relaxTlsLdToLe()applies canned code block presumably designed for a differentcallthan the one we have https://github.com/llvm/llvm-project/blob/llvmorg-15.0.6/lld/ELF/Arch/X86.cpp#L462Anyway, there you go. I don't know if this
.ois ABI compliant, I don't know if this is a valid candidate for some other LD->LE transition, I don't know what a minimal example of TLS-using code that produces thelea-callwith these relocs would look like, I'm just an end user chasing after a broken binary I got shipped.The text was updated successfully, but these errors were encountered: