[llvm] 8ce45f9 - BPF: fix relocation types in lib/Object/RelocationResolver.cpp

Yonghong Song via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 7 20:59:46 PDT 2021


Author: Yonghong Song
Date: 2021-06-07T20:59:21-07:00
New Revision: 8ce45f97283460a330201a199e686e8e088805e0

URL: https://github.com/llvm/llvm-project/commit/8ce45f97283460a330201a199e686e8e088805e0
DIFF: https://github.com/llvm/llvm-project/commit/8ce45f97283460a330201a199e686e8e088805e0.diff

LOG: BPF: fix relocation types in lib/Object/RelocationResolver.cpp

Commit 6a2ea84600ba ("BPF: Add more relocation kinds")
added new relocations R_BPF_64_ABS64 and R_BPF_64_ABS32
for normal 64-bit and 32-bit data relocations.
This is to replace some of functionalities with
R_BPF_64_64 and R_BPF_64_32 so that new R_BPF_64_64
and R_BPF_64_32 semantics are for ld_imm64 and
call instructions only.

The BPF support in lib/Object/RelocationResolver.cpp
is used to perform normal data relocations for
the case like DWARFObjInMemory with an object file
(search function getRelocationResolver() in file
DebugInfo/DWARF/DWARFContext.cpp) or llvm-readobj
to dump ".stack_sizes" section data.
In all these casees, normal 64-bit and 32-bit relocations
are performed and such resolution resolution
is exactly what implemented in RelocationResolver.cpp.

But Commit 6a2ea84600ba missed to change
R_BPF_64_64/R_BPF_64_32 to R_BPF_64_ABS64/R_BPF_64_ABS32.
This patch fixed the issue and added a test for it
with llvm-readobj dumping ".stack_sizes" section.

Differential Revision: https://reviews.llvm.org/D103864

Added: 
    llvm/test/Object/BPF/lit.local.cfg
    llvm/test/Object/BPF/yaml2obj-elf-bpf-rel.yaml

Modified: 
    llvm/lib/Object/RelocationResolver.cpp

Removed: 
    


################################################################################
diff  --git a/llvm/lib/Object/RelocationResolver.cpp b/llvm/lib/Object/RelocationResolver.cpp
index eee36f7f3de92..7df9b97de5bdb 100644
--- a/llvm/lib/Object/RelocationResolver.cpp
+++ b/llvm/lib/Object/RelocationResolver.cpp
@@ -89,8 +89,8 @@ static uint64_t resolveAArch64(uint64_t Type, uint64_t Offset, uint64_t S,
 
 static bool supportsBPF(uint64_t Type) {
   switch (Type) {
-  case ELF::R_BPF_64_32:
-  case ELF::R_BPF_64_64:
+  case ELF::R_BPF_64_ABS32:
+  case ELF::R_BPF_64_ABS64:
     return true;
   default:
     return false;
@@ -100,9 +100,9 @@ static bool supportsBPF(uint64_t Type) {
 static uint64_t resolveBPF(uint64_t Type, uint64_t Offset, uint64_t S,
                            uint64_t LocData, int64_t /*Addend*/) {
   switch (Type) {
-  case ELF::R_BPF_64_32:
+  case ELF::R_BPF_64_ABS32:
     return (S + LocData) & 0xFFFFFFFF;
-  case ELF::R_BPF_64_64:
+  case ELF::R_BPF_64_ABS64:
     return S + LocData;
   default:
     llvm_unreachable("Invalid relocation type");

diff  --git a/llvm/test/Object/BPF/lit.local.cfg b/llvm/test/Object/BPF/lit.local.cfg
new file mode 100644
index 0000000000000..a4ab2624af614
--- /dev/null
+++ b/llvm/test/Object/BPF/lit.local.cfg
@@ -0,0 +1,2 @@
+if not 'BPF' in config.root.targets:
+    config.unsupported = True

diff  --git a/llvm/test/Object/BPF/yaml2obj-elf-bpf-rel.yaml b/llvm/test/Object/BPF/yaml2obj-elf-bpf-rel.yaml
new file mode 100644
index 0000000000000..23c77a81e4e82
--- /dev/null
+++ b/llvm/test/Object/BPF/yaml2obj-elf-bpf-rel.yaml
@@ -0,0 +1,86 @@
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -r --stack-sizes %t | FileCheck %s
+
+# CHECK:      Relocations [
+# CHECK-NEXT:   Section (3) .rel.text {
+# CHECK-NEXT:     0x0 R_BPF_64_64 g
+# CHECK-NEXT:   }
+# CHECK-NEXT:   Section (5) .rel.stack_sizes {
+# CHECK-NEXT:     0x0 R_BPF_64_ABS64 .text
+# CHECK-NEXT:   }
+# CHECK-NEXT: ]
+# CHECK:      StackSizes [
+# CHECK-NEXT:   Entry {
+# CHECK-NEXT:     Function: test
+# CHECK-NEXT:     Size: 0x0
+# CHECK-NEXT:   }
+# CHECK-NEXT: ]
+
+--- !ELF
+FileHeader:
+  Class:           ELFCLASS64
+  Data:            ELFDATA2LSB
+  Type:            ET_REL
+  Machine:         EM_BPF
+Sections:
+  - Name:            .text
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
+    AddressAlign:    0x8
+    Content:         '1801000000000000000000000000000061100000000000009500000000000000'
+  - Name:            .stack_sizes
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_LINK_ORDER ]
+    Link:            .text
+    AddressAlign:    0x1
+    Entries:
+      - Size:            0x0
+  - Name:            .bss
+    Type:            SHT_NOBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    AddressAlign:    0x4
+    Size:            0x4
+  - Name:            .rel.text
+    Type:            SHT_REL
+    Link:            .symtab
+    AddressAlign:    0x8
+    Info:            .text
+    Relocations:
+      - Symbol:          g
+        Type:            R_BPF_64_64
+  - Name:            .rel.stack_sizes
+    Type:            SHT_REL
+    Link:            .symtab
+    AddressAlign:    0x8
+    Info:            .stack_sizes
+    Relocations:
+      - Symbol:          .text
+        Type:            R_BPF_64_ABS64
+  - Type:            SectionHeaderTable
+    Sections:
+      - Name:            .strtab
+      - Name:            .text
+      - Name:            .rel.text
+      - Name:            .stack_sizes
+      - Name:            .rel.stack_sizes
+      - Name:            .bss
+      - Name:            .symtab
+      - Name:            .shstrtab
+Symbols:
+  - Name:            t.c
+    Type:            STT_FILE
+    Index:           SHN_ABS
+  - Name:            .text
+    Type:            STT_SECTION
+    Section:         .text
+  - Name:            test
+    Type:            STT_FUNC
+    Section:         .text
+    Binding:         STB_GLOBAL
+    Size:            0x20
+  - Name:            g
+    Type:            STT_OBJECT
+    Section:         .bss
+    Binding:         STB_GLOBAL
+    Size:            0x4
+...


        


More information about the llvm-commits mailing list