[ELF] Support a few more SPARCv9 relocations

[LemonBoy]

Summary

Implemented a bunch of relocations found in binaries with medium/large code model and the Local-Exec TLS model. The binaries link and run fine in Qemu.
In addition, the emulation elf64_sparc is now recognized.

[MaskRay]

My immediate reaction is "isn't Sparc an abandoned architecture?" See https://en.wikipedia.org/wiki/SPARC and https://lists.freebsd.org/pipermail/freebsd-sparc64/2020-January/010192.html

Though, no objection. You may still need some basic tests, similar to test/ELF/ppc32-* I tried hard to keep the number of tests small yet complete. Does sparc64 use TLS variant 2?

[jrtc27]

Just as a note for things that are still missing:

• GD/LD/IE TLS (you mentioned IE TLS, but this only does *LE*)
• The HIX22/LOX10 (and others) family for GOTDATA that replaces R_SPARC_GOT22/10
• R_SPARC_REGISTER, needed to mark how each of the %g[2367] (could have the exact numbers wrong, they're from deep in my memory) are being used by the object files to as to ensure they don't conflict. It's a very unusual relocation (refers to magic STT_SPARC_REGISTER symbols) that should have designed using something other than a relocation...

There may be others, but as one of the SPARC porters in Debian that's what I can think of off the top of my head.

[jrtc27]

In D77672#1967700, @MaskRay wrote:

My immediate reaction is "isn't Sparc an abandoned architecture?" See https://en.wikipedia.org/wiki/SPARC and https://lists.freebsd.org/pipermail/freebsd-sparc64/2020-January/010192.html

Though, no objection. You may still need some basic tests, similar to test/ELF/ppc32-* I tried hard to keep the number of tests small yet complete. Does sparc64 use TLS variant 2?

For FreeBSD, yes, and mostly within LLVM (certainly nobody really uses LLD). The non-release Debian architecture is still going strong though. SPARC (32-bit and 64-bit) is basically the same as IA-32 (although not with the weird calling convention and triple leading underscores), and one of the architectures described in Drepper's original TLS white paper, so yes, variant II.

[MaskRay]

In D77672#1968122, @jrtc27 wrote:

In D77672#1967700, @MaskRay wrote:

My immediate reaction is "isn't Sparc an abandoned architecture?" See https://en.wikipedia.org/wiki/SPARC and https://lists.freebsd.org/pipermail/freebsd-sparc64/2020-January/010192.html

Though, no objection. You may still need some basic tests, similar to test/ELF/ppc32-* I tried hard to keep the number of tests small yet complete. Does sparc64 use TLS variant 2?

For FreeBSD, yes, and mostly within LLVM (certainly nobody really uses LLD). The non-release Debian architecture is still going strong though. SPARC (32-bit and 64-bit) is basically the same as IA-32 (although not with the weird calling convention and triple leading underscores), and one of the architectures described in Drepper's original TLS white paper, so yes, variant II.

If the intention is improve Sparc, the integrated assembler issues (rL254199) should be addressed.

https://lists.llvm.org/pipermail/llvm-dev/2017-June/114437.html mentioned a plan to revive the support but I believe the situation has not been improved... The codegen maintainer has moved on (left) since 2014..

[ruiu]

Improving SPARC support is fine as long as we don't need to do something special for the ISA. But since no active maintainers have a SPARC machine, it is hard to find bugs in SPARC. Can you add tests for the new relocations?

[jrtc27]

In D77672#1968560, @ruiu wrote:

Improving SPARC support is fine as long as we don't need to do something special for the ISA. But since no active maintainers have a SPARC machine, it is hard to find bugs in SPARC. Can you add tests for the new relocations?

For what it's worth, I have access to various SPARC machines, so can test things as needed. Also, the GCC compile farm (https://cfarm.tetaneutral.net/machines/list/) has multiple SPARC machines; in particular, gcc202 is managed by us Debian sparc64 porters, and has a beefy 64 cores and 64 GiB on a T5 (which, unlike some of the earlier UltraSparcs, has decent single-threaded performance too), so it should be easy for maintainers to test things if they're interested enough. The compile farm is a great resource in general that is really easy to sign up for and most don't know about.

[ruiu]

In D77672#1968587, @jrtc27 wrote:

In D77672#1968560, @ruiu wrote:

Improving SPARC support is fine as long as we don't need to do something special for the ISA. But since no active maintainers have a SPARC machine, it is hard to find bugs in SPARC. Can you add tests for the new relocations?

For what it's worth, I have access to various SPARC machines, so can test things as needed. Also, the GCC compile farm (https://cfarm.tetaneutral.net/machines/list/) has multiple SPARC machines; in particular, gcc202 is managed by us Debian sparc64 porters, and has a beefy 64 cores and 64 GiB on a T5 (which, unlike some of the earlier UltraSparcs, has decent single-threaded performance too), so it should be easy for maintainers to test things if they're interested enough. The compile farm is a great resource in general that is really easy to sign up for and most don't know about.

If the SPARC community is interested in lld, it shouldn't be too hard to make lld usable for SPARC, so it is up to the community.

[LemonBoy]

I've added a few tests that cover the newly-added relocations plus a few more, R_SPARC_LM22 is not yet tested because LLVM as doesn't recognize it but I already have a patch ready for that.

My immediate reaction is "isn't Sparc an abandoned architecture?"

Well somebody asked if Zig could target sparc64/linux so I guess there's at least a small group of users interested in it. Since we exclusively use lld I decided to fix this roadblock, this patch isn't meant to be exhaustive but focuses on the missing relocations I've found in the binaries produced by Zig.

Does sparc64 use TLS variant 2?

AFAIR it's one of the few non-x86 arches to use it

you mentioned IE TLS, but this only does *LE*

Typo, the relocations also have "LE" in the name :)

[brad]

In D77672#1967700, @MaskRay wrote:

My immediate reaction is "isn't Sparc an abandoned architecture?" See https://en.wikipedia.org/wiki/SPARC and https://lists.freebsd.org/pipermail/freebsd-sparc64/2020-January/010192.html

Though, no objection. You may still need some basic tests, similar to test/ELF/ppc32-* I tried hard to keep the number of tests small yet complete. Does sparc64 use TLS variant 2?

For FreeBSD that is the case. FreeBSD/sparc64 always seemed to be on life support. Unlike FreeBSD / NetBSD, OpenBSD's sparc64 port is fully supported and supports the latest and greatest with regard to sparc64.

We're very close to switching to Clang as the system compiler on sparc64.

[MaskRay]

lld/test/ELF/sparcv9-reloc.s

37

Indenting by 2 should be sufficient.

lld/test/ELF/sparcv9-tls-le.s

6

Add a ## comment how the values are computed.

[MaskRay]

Can you refer me to the sparc psABI so that I can verify the implementation?

lld/test/ELF/sparcv9-reloc.s

5

objdump -s does not need --no-show-raw-insn.

[LemonBoy]

In D77672#1976345, @MaskRay wrote:

Can you refer me to the sparc psABI so that I can verify the implementation?

I've followed this document by Oracle, the TLS ones are in chapter 8.

[MaskRay]

lld/ELF/Driver.cpp

151

Add a test similar to emulation-arm.s

The other emulation-* have verbose llvm-readobj output. Don't copy them.

[LemonBoy]

I really hate phabricator

[MaskRay]

lld/test/ELF/emulation-sparc.s

2 ↗

(On Diff #257434)

You can drop -unknown-linux. FreeBSD/OpenBSD's triples don't have the OS part. Without the OS part, it usually means the generic ELF behavior.

For an object file, it is usually better to use %t.o or similar.

For an executable, %t usually suffices. When there are more than one, Use %t1 %t2 ...

(I know that some existing tests don't follow the convention.) And the existing emulation-* do not follow the best practice.

8 ↗

(On Diff #257434)

Add -T before a linker script (you may name it %t.lds, shorter than %t.script)

GNU ld warns without -T

10 ↗

(On Diff #257434)

If there are no other prefixes, just use the FileCheck default CHECK. You can omit --check-prefix as well.

[LemonBoy]

Minor changes to the test case.

[MaskRay]

LGTM.

[LemonBoy]

Can you (or anyone) commit this on my behalf? I don't have commit access.

lld/test/ELF/emulation-sparc.s

10 ↗

(On Diff #257434)

I've picked the V9 prefix as LLD may want to support the 32bit variants some day

[MaskRay]

Adjust the tests a bit
Update the description

[MaskRay]

Adjust

lld/ELF/Arch/SPARCV9.cpp

 
 RelExpr SPARCV9::getRelExpr(RelType type, const Symbol &s,
                             const uint8_t *loc) const {
   switch (type) {
   case R_SPARC_32:
   case R_SPARC_UA32:
   case R_SPARC_64:
   case R_SPARC_UA64:
+  case R_SPARC_H44:
+  case R_SPARC_M44:
+  case R_SPARC_L44:
+  case R_SPARC_HH22:
+  case R_SPARC_HM10:
+  case R_SPARC_LM22:
+  case R_SPARC_HI22:
+  case R_SPARC_LO10:
     return R_ABS;
   case R_SPARC_PC10:
   case R_SPARC_PC22:
   case R_SPARC_DISP32:
   case R_SPARC_WDISP30:
     return R_PC;
   case R_SPARC_GOT10:
     return R_GOT_OFF;
   case R_SPARC_GOT22:
     return R_GOT_OFF;
   case R_SPARC_WPLT30:
     return R_PLT_PC;
   case R_SPARC_NONE:
     return R_NONE;
+  case R_SPARC_TLS_LE_HIX22:
+  case R_SPARC_TLS_LE_LOX10:
+    return R_TLS;
   default:
     error(getErrorLocation(loc) + "unknown relocation (" + Twine(type) +
           ") against symbol " + toString(s));
     return R_NONE;
   }
 }
 
 void SPARCV9::relocate(uint8_t *loc, const Relocation &rel,
case R_SPARC_WPLT30:
     break;
   case R_SPARC_22:
     // V-imm22
     checkUInt(loc, val, 22, rel);
     write32be(loc, (read32be(loc) & ~0x003fffff) | (val & 0x003fffff));
     break;
   case R_SPARC_GOT22:
   case R_SPARC_PC22:
+  case R_SPARC_LM22:
     // T-imm22
     write32be(loc, (read32be(loc) & ~0x003fffff) | ((val >> 10) & 0x003fffff));
     break;
+  case R_SPARC_HI22:
+    // V-imm22
+    checkUInt(loc, val >> 10, 22, rel);
+    write32be(loc, (read32be(loc) & ~0x003fffff) | ((val >> 10) & 0x003fffff));
+    break;
   case R_SPARC_WDISP19:
     // V-disp19
     checkInt(loc, val, 21, rel);
     write32be(loc, (read32be(loc) & ~0x0007ffff) | ((val >> 2) & 0x0007ffff));
     break;
   case R_SPARC_GOT10:
   case R_SPARC_PC10:
     // T-simm10
     write32be(loc, (read32be(loc) & ~0x000003ff) | (val & 0x000003ff));
     break;
+  case R_SPARC_LO10:
+    // T-simm13
+    write32be(loc, (read32be(loc) & ~0x00001fff) | (val & 0x000003ff));
+    break;
   case R_SPARC_64:
   case R_SPARC_UA64:
     // V-xword64
     write64be(loc, val);
     break;
+  case R_SPARC_HH22:
+    // V-imm22
+    checkUInt(loc, val >> 42, 22, rel);
+    write32be(loc, (read32be(loc) & ~0x003fffff) | ((val >> 42) & 0x003fffff));
+    break;
+  case R_SPARC_HM10:
+    // T-simm13
+    write32be(loc, (read32be(loc) & ~0x00001fff) | ((val >> 32) & 0x000003ff));
+    break;
+  case R_SPARC_H44:
+    // V-imm22
+    checkUInt(loc, val >> 22, 22, rel);
+    write32be(loc, (read32be(loc) & ~0x003fffff) | ((val >> 22) & 0x003fffff));
+    break;
+  case R_SPARC_M44:
+    // T-imm10
+    write32be(loc, (read32be(loc) & ~0x000003ff) | ((val >> 12) & 0x000003ff));
+    break;
+  case R_SPARC_L44:
+    // T-imm13
+    write32be(loc, (read32be(loc) & ~0x00001fff) | (val & 0x00000fff));
+    break;
+  case R_SPARC_TLS_LE_HIX22:
+    // T-imm22
+    write32be(loc, (read32be(loc) & ~0x003fffff) | ((~val >> 10) & 0x003fffff));
+    break;
+  case R_SPARC_TLS_LE_LOX10:
+    // T-simm13
+    write32be(loc, (read32be(loc) & ~0x00001fff) | (val & 0x000003ff) | 0x1C00);
+    break;
   default:
     llvm_unreachable("unknown relocation");
   }
 }
 
 void SPARCV9::writePlt(uint8_t *buf, const Symbol & /*sym*/,
                        uint64_t pltEntryAddr) const {
   const uint8_t pltData[] = {

lld/ELF/Driver.cpp

std::pair<ELFKind, uint16_t> ret =
           .Case("elf64btsmip", {ELF64BEKind, EM_MIPS})
           .Case("elf64ltsmip", {ELF64LEKind, EM_MIPS})
           .Case("elf64lriscv", {ELF64LEKind, EM_RISCV})
           .Case("elf64ppc", {ELF64BEKind, EM_PPC64})
           .Case("elf64lppc", {ELF64LEKind, EM_PPC64})
           .Cases("elf_amd64", "elf_x86_64", {ELF64LEKind, EM_X86_64})
           .Case("elf_i386", {ELF32LEKind, EM_386})
           .Case("elf_iamcu", {ELF32LEKind, EM_IAMCU})
+          .Case("elf64_sparc", {ELF64BEKind, EM_SPARCV9})
           .Default({ELFNoneKind, EM_NONE});
 
   if (ret.first == ELFNoneKind)
     error("unknown emulation: " + emul);
   return std::make_tuple(ret.first, ret.second, osabi);
 }
 
 // Returns slices of MB by parsing MB as an archive file.

lld/ELF/InputSection.cpp

case EM_PPC64:
     // to allow a signed 16-bit offset to reach 0x1000 of TCB/thread-library
     // data and 0xf000 of the program's TLS segment.
     return s.getVA(0) + (tls->p_vaddr & (tls->p_align - 1)) - 0x7000;
   case EM_RISCV:
     return s.getVA(0) + (tls->p_vaddr & (tls->p_align - 1));
 
     // Variant 2.
   case EM_HEXAGON:
+  case EM_SPARCV9:
   case EM_386:
   case EM_X86_64:
     return s.getVA(0) - tls->p_memsz -
            ((-tls->p_vaddr - tls->p_memsz) & (tls->p_align - 1));
   default:
     llvm_unreachable("unhandled Config->EMachine");
   }
 }

lld/test/ELF/sparcv9-reloc.s

+# REQUIRES: sparc
+# RUN: llvm-mc -filetype=obj -triple=sparcv9 %s -o %t.o
+# RUN: ld.lld %t.o --defsym=a=0x0123456789ABCDEF --defsym=b=0x0123456789A --defsym=c=0x01234567 -o %t
+# RUN: llvm-objdump -d --no-show-raw-insn %t | FileCheck %s
+# RUN: llvm-objdump -s --no-show-raw-insn %t | FileCheck --check-prefix=HEX %s
+
+## R_SPARC_HH22, R_SPARC_HM10
+.section .ABS_64,"ax",@progbits
+  sethi %hh(a), %o0
+  or    %o0, %hm(a), %o0
+# CHECK-LABEL: section .ABS_64:
+# CHECK: sethi 18641, %o0
+# CHECK-NEXT: or %o0, 359, %o0
+
+## R_SPARC_H44, R_SPARC_M44, R_SPARC_L44
+.section .ABS_44,"ax",@progbits
+  sethi %h44(b), %o0
+  or    %o0, %m44(b), %o0
+  sllx  %o0, 12, %o0
+  or    %o0, %l44(b), %o0
+# CHECK-LABEL: section .ABS_44:
+# CHECK: sethi 18641, %o0
+# CHECK: or %o0, 359, %o0
+# CHECK: or %o0, 2202, %o0
+
+## R_SPARC_HI22, R_SPARC_LO10
+.section .ABS_32,"ax",@progbits
+  sethi %hi(c), %o0
+  or    %o0, %lo(c), %o0
+# CHECK-LABEL: section .ABS_32:
+# CHECK: sethi 18641, %o0
+# CHECK-NEXT: or %o0, 359, %o0
+
+## R_SPARC_64, R_SPARC_32
+.section .ABS_DATA,"ax",@progbits
+  .quad a
+  .long c
+# HEX-LABEL: section .ABS_DATA:
+# HEX-NEXT: 01234567 89abcdef 01234567

lld/test/ELF/sparcv9-tls-le.s

+# REQUIRES: sparc
+# RUN: llvm-mc -filetype=obj -triple=sparcv9 %s -o %t.o
+# RUN: ld.lld %t.o -o %t
+# RUN: llvm-objdump -d --no-show-raw-insn %t | FileCheck --check-prefix=LE %s
+
+## %hix(@tpoff(a)) = ~(st_value(a) - 1026) >> 10 = 1
+## %lo(@tpoff(a)) = (st_value(a) - 1026) & 0x3ff | 0x1c00 = -2 (0x1ffe)
+sethi %tle_hix22(a), %o0
+xor   %o0, %tle_lox10(a), %o0
+# LE: sethi 1, %o0
+# LE-NEXT: xor %o0, -2, %o0
+
+.section .tbss
+.globl a
+a:
+.zero 1024+2
+b: