bpf: disable DwarfUsesRelocationsAcrossSections

The pahole does not work with BPF backend properly:

  -bash-4.2$ cat test.c
  struct test_t {
    int a;
    int b;
  };
  int test(struct test_t *s) {
    return s->a;
  }
  -bash-4.2$ clang -g -O2 -target bpf -c test.c
  -bash-4.2$ pahole test.o
  struct clang version 7.0.0 (trunk 325446) (llvm/trunk 325464) {
          clang version 7.0.0 (trunk 325446) (llvm/trunk 325464) clang version 7.0.0 (trunk 325446) (llvm/trunk 325464); /*     0     4 */
          clang version 7.0.0 (trunk 325446) (llvm/trunk 325464) clang version 7.0.0 (trunk 325446) (llvm/trunk 325464); /*     4     4 */

          /* size: 8, cachelines: 1, members: 2 */
          /* last cacheline: 8 bytes */
  };
  -bash-4.2$

The reason is that BPF backend is not yet implemented in elfutils backend
  https://github.com/threatstack/elfutils/tree/master/backends
and pahole depends on elfutils for dwarf parsing and resolving relocation.

More specifically, the unsupported relocation in .debug_info for type/member name
against symbol table caused the incorrect result above. The following is
the raw .rel.debug_info for the above example,
  Hex dump of section '.rel.debug_info':
    0x00000000 06000000 00000000 0a000000 0b000000 ................
    0x00000010 0c000000 00000000 0a000000 01000000 ................
    0x00000020 12000000 00000000 0a000000 02000000 ................
    0x00000030 16000000 00000000 0a000000 0e000000 ................
    0x00000040 1a000000 00000000 0a000000 03000000 ................
               ----------------- -------- --------
                reloc location     type   symtab index

  Hex dump of section '.debug_info':
    0x00000000 7b000000 04000000 00000801 00000000 {...............
    0x00000010 0c000000 00000000 00000000 00000000 ................
    0x00000020 00000000 00001000 00000200 00000000 ................

Based on "type", the proper value will be extracted from symbol table
and filled in .debug_info so later on .debug_info can be properly
resolved against debug strings.

There are two ways to fix this problem. One is to fix elfutils by adding
BPF support which is desirable. This could take a long time and won't work
with already deployed pahole. For a short term workaround, we can disable
dwarf cross-section relation which specifically avoids debug_info and
symbol table cross relocation. This should help any dwarf-related tool
which has not implement BPF specific relocations yet.

Now .rel.debug_info does not have any relocation for symbol table and
.debug_info itself contains necessary relocation information by itself.
  Hex dump of section '.debug_info':
    0x00000000 7b000000 04000000 00000801 00000000 {...............
    0x00000010 0c003700 00000000 00003e00 00000000 ..7.......>.....
    0x00000020 00000000 00001000 00000200 00000000 ................
  location 0xc has 0, 0x12 has 0x37, 0x1a has 0x3e in place which
  will be used in relocation resolution. Here, the values of 0, 0x37 and 0x3e
  are offset in .debug_str section.
Please note the difference between two above .debug_info dumps.

With the fix, pahole works properly with BPF backend:
  -bash-4.2$ clang -O2 -g -target bpf -c test.c
  -bash-4.2$ pahole test.o
  struct test_t {
          int                        a;                    /*     0     4 */
          int                        b;                    /*     4     4 */

          /* size: 8, cachelines: 1, members: 2 */
          /* last cacheline: 8 bytes */
  };

Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 325735

1 files changed, 2 insertions, 0 deletions

diff --git a/llvm/lib/Target/BPF/MCTargetDesc/BPFMCAsmInfo.h b/llvm/lib/Target/BPF/MCTargetDesc/BPFMCAsmInfo.h
index fd7c97bf1f0..fa06f31add9 100644
--- a/llvm/lib/Target/BPF/MCTargetDesc/BPFMCAsmInfo.h
+++ b/llvm/lib/Target/BPF/MCTargetDesc/BPFMCAsmInfo.h
@@ -37,6 +37,8 @@ public:
     ExceptionsType = ExceptionHandling::DwarfCFI;
     MinInstAlignment = 8;
 
+    DwarfUsesRelocationsAcrossSections = false;
+
     // the default is 4 and it only affects dwarf elf output
     // so if not set correctly, the dwarf data will be
     // messed up in random places by 4 bytes. .debug_line