llvm-objdump disassemly does not correctly decode data references in PIC code?

[MatzeB]

Reproducer:

test.c:

int foo = 0;
int get_foo() { return foo; }
void set_foo(int val) { foo = val; }

compile and dump:

$ clang -fPIC -shared -o libtest.so test.c
$ llvm-objdump -d  libtest.so
...
0000000000001100 <get_foo>:
    1100: 55                            pushq   %rbp
    1101: 48 89 e5                      movq    %rsp, %rbp
    1104: 48 8b 05 dd 2e 00 00          movq    0x2edd(%rip), %rax      # 0x3fe8 <__gmon_start__+0x3fe8>
    110b: 8b 00                         movl    (%rax), %eax
    110d: 5d                            popq    %rbp
    110e: c3                            retq
    110f: 90                            nop

0000000000001110 <set_foo>:
    1110: 55                            pushq   %rbp
    1111: 48 89 e5                      movq    %rsp, %rbp
    1114: 89 7d fc                      movl    %edi, -0x4(%rbp)
    1117: 8b 4d fc                      movl    -0x4(%rbp), %ecx
    111a: 48 8b 05 c7 2e 00 00          movq    0x2ec7(%rip), %rax      # 0x3fe8 <__gmon_start__+0x3fe8>
    1121: 89 08                         movl    %ecx, (%rax)
    1123: 5d                            popq    %rbp
    1124: c3                            retq

Note that this says __gmon_start__+0x3fe8 at the place where it references the foo variable (or rather references the entry for foo in the PLT table I think).

GNU objdump produces a more reasonable result:

...
   1104:       48 8b 05 dd 2e 00 00    mov    0x2edd(%rip),%rax        # 3fe8 <foo@@Base-0x3c>
...
   111a:       48 8b 05 c7 2e 00 00    mov    0x2ec7(%rip),%rax        # 3fe8 <foo@@Base-0x3c>
...

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objdump

Author: Matthias Braun (MatzeB)

Reproducer:

test.c:

int foo = 0;
int get_foo() { return foo; }
void set_foo(int val) { foo = val; }

compile and dump:

$ clang -fPIC -shared -o libtest.so test.c
$ llvm-objdump -d  libtest.so
...
0000000000001100 <get_foo>:
    1100: 55                            pushq   %rbp
    1101: 48 89 e5                      movq    %rsp, %rbp
    1104: 48 8b 05 dd 2e 00 00          movq    0x2edd(%rip), %rax      # 0x3fe8 <__gmon_start__+0x3fe8>
    110b: 8b 00                         movl    (%rax), %eax
    110d: 5d                            popq    %rbp
    110e: c3                            retq
    110f: 90                            nop

0000000000001110 <set_foo>:
    1110: 55                            pushq   %rbp
    1111: 48 89 e5                      movq    %rsp, %rbp
    1114: 89 7d fc                      movl    %edi, -0x4(%rbp)
    1117: 8b 4d fc                      movl    -0x4(%rbp), %ecx
    111a: 48 8b 05 c7 2e 00 00          movq    0x2ec7(%rip), %rax      # 0x3fe8 <__gmon_start__+0x3fe8>
    1121: 89 08                         movl    %ecx, (%rax)
    1123: 5d                            popq    %rbp
    1124: c3                            retq

Note that this says __gmon_start__+0x3fe8 at the place where it references the foo variable.

GNU objdump gets this right and says:

...
   1104:       48 8b 05 dd 2e 00 00    mov    0x2edd(%rip),%rax        # 3fe8 &lt;foo@@<!-- -->Base-0x3c&gt;
...
   111a:       48 8b 05 c7 2e 00 00    mov    0x2ec7(%rip),%rax        # 3fe8 &lt;foo@@<!-- -->Base-0x3c&gt;
...

[jh7370]

I've reproduced this using clang-19. I haven't attempted with main, as I don't have a Linux clone of LLVM currently that I can easily build and test with.

Note that this says gmon_start+0x3fe8 at the place where it references the foo variable (or rather references the entry for foo in the PLT table I think).

To be more precise, the reference is to the .got (specifically, the entry there relevant to foo). There is a dynamic relocation that patches this reference and is targeting the foo symbol itself. I presume that GNU objdump is achieving this by following this reference chain through the .got to the actual symbol, although I'm not sure what "Base-0x3c" is supposed to mean (what is "Base"?).

llvm-objdump instead seems to have picked the undefined __gmon_start__ symbol, even though the target has nothing to do with that symbol. That seems like a bug in and of itself, but one that will probably best be resolved by simply implementing this GOT chaining.

I'm not especially up-to-speed with the llvm-objdump disassembler details. @MaskRay may be able to provide more assistance.