[RelocationResolver][Xtensa] Implement R_XTENSA_32

[yamt]

This makes llvm-dwarfdump work on Xtensa ELF objects.

Reference: https://github.com/jcmvbkbc/xtensa-abi/blob/master/relocations

[llvmbot]

@llvm/pr-subscribers-debuginfo

@llvm/pr-subscribers-llvm-binary-utilities

Author: YAMAMOTO Takashi (yamt)

Changes

This makes llvm-dwarfdump work on Xtensa ELF objects.

Reference: https://github.com/jcmvbkbc/xtensa-abi/blob/master/relocations

---

Full diff: https://github.com/llvm/llvm-project/pull/96311.diff

1 Files Affected:

• (modified) llvm/lib/Object/RelocationResolver.cpp (+27-2)

diff --git a/llvm/lib/Object/RelocationResolver.cpp b/llvm/lib/Object/RelocationResolver.cpp
index 564d9da78e97d..b404a79966b9d 100644
--- a/llvm/lib/Object/RelocationResolver.cpp
+++ b/llvm/lib/Object/RelocationResolver.cpp
@@ -310,6 +310,28 @@ static uint64_t resolveX86(uint64_t Type, uint64_t Offset, uint64_t S,
   }
 }
 
+static bool supportsXtensa(uint64_t Type) {
+  switch (Type) {
+  case ELF::R_XTENSA_NONE:
+  case ELF::R_XTENSA_32:
+    return true;
+  default:
+    return false;
+  }
+}
+
+static uint64_t resolveXtensa(uint64_t Type, uint64_t Offset, uint64_t S,
+                              uint64_t LocData, int64_t Addend) {
+  switch (Type) {
+  case ELF::R_XTENSA_NONE:
+    return LocData;
+  case ELF::R_XTENSA_32:
+    return (S + Addend + LocData) & 0xFFFFFFFF;
+  default:
+    llvm_unreachable("Invalid relocation type");
+  }
+}
+
 static bool supportsPPC32(uint64_t Type) {
   switch (Type) {
   case ELF::R_PPC_ADDR32:
@@ -820,6 +842,8 @@ getRelocationResolver(const ObjectFile &Obj) {
     switch (Obj.getArch()) {
     case Triple::x86:
       return {supportsX86, resolveX86};
+    case Triple::xtensa:
+      return {supportsXtensa, resolveXtensa};
     case Triple::ppcle:
     case Triple::ppc:
       return {supportsPPC32, resolvePPC32};
@@ -885,11 +909,12 @@ uint64_t resolveRelocation(RelocationResolver Resolver, const RelocationRef &R,
 
       if (GetRelSectionType() == ELF::SHT_RELA) {
         Addend = getELFAddend(R);
-        // LoongArch and RISCV relocations use both LocData and Addend.
+        // LoongArch, RISCV, and Xtensa relocations use both LocData and Addend.
         if (Obj->getArch() != Triple::loongarch32 &&
             Obj->getArch() != Triple::loongarch64 &&
             Obj->getArch() != Triple::riscv32 &&
-            Obj->getArch() != Triple::riscv64)
+            Obj->getArch() != Triple::riscv64 &&
+            Obj->getArch() != Triple::xtensa)
           LocData = 0;
       }
     }

[dwblaikie]

Please add some test coverage

[yamt]

Please add some test coverage

i added a test

[yamt]

@dwblaikie any other concerns?

[dwblaikie]

could use assembly labels to compute the length here to make it easier to update the test in the future?

[yamt]

well, i just followed the existing practice: https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml

[dwblaikie]

Perhaps the simplest thing to do would be to have only a .debug_addr section with some relocatable addresses in it?

Could the assembly actually include the symbol references that would generate the relocations (can llvm-mc generate these relocations?) so they don't have to be hand-crafted in the IR?

[yamt]

Perhaps the simplest thing to do would be to have only a .debug_addr section with some relocatable addresses in it?

i'm not familiar enough with dwarf to say if it's simpler/reasonable.

Could the assembly actually include the symbol references that would generate the relocations (can llvm-mc generate these relocations?) so they don't have to be hand-crafted in the IR?

i'm sure the espressif fork of the llvm can produce R_XTENSA_32.
but i thought xtensa support in the stock llvm was somehow incomplete.

[MaskRay]

We could drop R_*_NONE. It should not appear in relocation files.

[yamt]

i feel it's better for this kind of tools to handle more cases as far as it's legal and easy.
anyway your comment isn't specific to this PR, right?

[MaskRay]

Yes, the comment is specific to this PR.

RelocationResolver is to handle static relocations. While R_NONE might be defined by a psABI, in practice it's always a toolchain bug when RelocationResolver has to resolve R_NONE. We should not handle unnecessary relocations.

[yamt]

Yes, the comment is specific to this PR.

RelocationResolver is to handle static relocations. While R___NONE might be defined by a psABI, in practice it's always a toolchain bug when RelocationResolver has to resolve R___NONE. We should not handle unnecessary relocations.

do you mean that for some reasons your rationale is specific to xtensa (this PR)
and doesn't apply to other non-xtensa relocations like R_X86_64_NONE?