Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

llvm-objdump doesn't list symbols in ppc64 -mabi=elfv1 objects #48979

Open Quuxplusone opened 3 years ago

Quuxplusone commented 3 years ago
Bugzilla Link PR50010
Status NEW
Importance P enhancement
Reported by наб (nabijaczleweli@nabijaczleweli.xyz)
Reported on 2021-04-17 03:27:57 -0700
Last modified on 2021-05-01 11:27:35 -0700
Version trunk
Hardware Other Linux
CC i@maskray.me, llvm-bugs@lists.llvm.org, nabijaczleweli@nabijaczleweli.xyz
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
Consider the following C code:
    int symbol_a(void) {
        return 'a';
    }

    int symbol_b(void) {
        return 'b';
    }

When built for ppc64el, everything appears in order:
    $ cc -target ppc64le-unknown-linux-gnu a.c -c -oa.o
    $ llvm-objdump -d a.o

    a.o:    file format elf64-powerpcle

    Disassembly of section .text:

    0000000000000000 <symbol_a>:
           0: 61 00 60 38   li 3, 97
           4: 20 00 80 4e   blr
                    ...
          14: 00 00 00 60   nop
          18: 00 00 00 60   nop
          1c: 00 00 00 60   nop

    0000000000000020 <symbol_b>:
          20: 62 00 60 38   li 3, 98
          24: 20 00 80 4e   blr
                    ...

But when building for ppc64, the symbol listing is gone:
    $ cc -target ppc64-unknown-linux-gnu a.c -c -oa.o
    $ llvm-objdump -d a.o

    a.o:    file format elf64-powerpc

    Disassembly of section .text:

    0000000000000000 <.text>:
           0: 38 60 00 61   li 3, 97
           4: 4e 80 00 20   blr
                    ...
          14: 38 60 00 62   li 3, 98
          18: 4e 80 00 20   blr
                    ...

Both object files have a symtab:
    $ llvm-objdump -h a.o

    a.o:    file format elf64-powerpcle

    Sections:
    Idx Name            Size     VMA              Type
      0                 00000000 0000000000000000
      1 .strtab         00000063 0000000000000000
      2 .text           00000034 0000000000000000 TEXT
      3 .comment        00000056 0000000000000000
      4 .note.GNU-stack 00000000 0000000000000000
      5 .eh_frame       00000040 0000000000000000 DATA
      6 .rela.eh_frame  00000030 0000000000000000
      7 .llvm_addrsig   00000000 0000000000000000
      8 .symtab         00000078 0000000000000000

    $ llvm-objdump -h a.o

    a.o:    file format elf64-powerpc

    Sections:
    Idx Name            Size     VMA              Type
      0                 00000000 0000000000000000
      1 .strtab         00000073 0000000000000000
      2 .text           00000028 0000000000000000 TEXT
      3 .opd            00000030 0000000000000000 DATA
      4 .rela.opd       00000060 0000000000000000
      5 .comment        00000056 0000000000000000
      6 .note.GNU-stack 00000000 0000000000000000
      7 .eh_frame       00000040 0000000000000000 DATA
      8 .rela.eh_frame  00000030 0000000000000000
      9 .llvm_addrsig   00000000 0000000000000000
     10 .symtab         00000090 0000000000000000

And on rudimentary inspexion, both objects' symtabs appear to contain the names.

My toolchain is as follows
    Debian clang version 13.0.0-++20210415102640+07edd7899392-1~exp1~20210415203405.1444
    Target: x86_64-pc-linux-gnu
    Thread model: posix
    InstalledDir: /bin
obtained from the current buster nightly packages.
Quuxplusone commented 3 years ago
ppc64-*-linux-gnu uses -mabi=elfv1 by default. llvm-objdump does not decode the
.opd section. See below, the symbols are defined relative to .opd

% llvm-objdump -t a.o

a.o:    file format elf64-powerpc

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 a.c
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 g     F .opd   0000000000000014 symbol_a
0000000000000000         *UND*  0000000000000000 .TOC.
0000000000000018 g     F .opd   0000000000000014 symbol_b

ppc64le-*-linux-gnu uses -mabi=elfv2 by default. ppc64/ppc64le -mabi=elfv2 is
similar to other targets.

This may be a wontfix because distributions are phasing out elfv1.