[PATCH] D102862: [lld][ELF][SPARC] Support TLS GD relocations
Jessica Clarke via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 20 13:49:15 PDT 2021
jrtc27 added inline comments.
================
Comment at: lld/ELF/Arch/SPARCV9.cpp:227
+ case R_SPARC_TLS_GD_ADD:
+ // add %r1, %r2, %r3 -> mov %g7, %r2, %r3
+ write32be(loc, (read32be(loc) & ~0x0007c000) | 0x0001c000);
----------------
LemonBoy wrote:
> jrtc27 wrote:
> > Do you mean `add %g7, %r2, %r3`?
> Yes, it's a typo I carried over from Gold as that's the only reference for the relaxation sequences.
The reference is the original Ulrich Drepper ELF TLS spec https://www.akkadia.org/drepper/tls.pdf
================
Comment at: lld/ELF/Relocations.cpp:291-294
+ // These relocations are applied on call instructions like
+ // call __tls_get_addr, %rel(sym)
+ // If this relocation won't be relaxed we have to replace it with a
+ // PLT-relative one to __tls_get_addr.
----------------
LemonBoy wrote:
> jrtc27 wrote:
> > Should this be more like hexagonNeedsTLSSymbol/hexagonTLSSymbolUpdate and combined with it, which has similar weirdness?
> No, I find this approach much cleaner than the late patching done for Hexagon.
> I also found that adding a PLT entry that late will fail to generate a PLT section if there was none in the input files.
Hm, it's a bit ugly. Maybe @MaskRay has ideas. Does that mean Hexagon is buggy, too?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D102862/new/
https://reviews.llvm.org/D102862
More information about the llvm-commits
mailing list