[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