problems when building for ppc64

[paleozogt]

In #156704 I misunderstood where the problem was. Clang seems to be ok when cross-compiling for ppc64(be), but ld.lld and llvm-objdump have problems with debug symbols.

Given a simple c file:

// test.c
int foobar(int v) {
   return v+1;
}

Build and link with gnu, but objdump with llvm, which doesn't seem to know where the symbols are:

$ powerpc64-linux-gnu-gcc -ffreestanding -O0 -c test.c -o test.ppc64.o
$ powerpc64-linux-gnu-ld -nostdlib test.ppc64.o -o test.ppc64.elf
$ llvm-objdump-14 -d test.ppc64.elf

test.ppc64.elf: file format elf64-powerpc

Disassembly of section .text:

00000000100000e8 <.text>:
100000e8: fb e1 ff f8   std 31, -8(1)
100000ec: f8 21 ff c1   stdu 1, -64(1)
100000f0: 7c 3f 0b 78   mr      31, 1
100000f4: 7c 69 1b 78   mr      9, 3
100000f8: 91 3f 00 70   stw 9, 112(31)
100000fc: 81 3f 00 70   lwz 9, 112(31)
10000100: 39 29 00 01   addi 9, 9, 1
10000104: 7d 29 07 b4   extsw 9, 9
10000108: 7d 23 4b 78   mr      3, 9
1000010c: 38 3f 00 40   addi 1, 31, 64
10000110: eb e1 ff f8   ld 31, -8(1)
10000114: 4e 80 00 20   blr
                ...
10000120: 80 01 00 01   lwz 0, 1(1)

Contrast that with gnu's objdump behavior:

$ powerpc64-linux-gnu-objdump -d test.ppc64.elf

test.ppc64.elf:     file format elf64-powerpc

Disassembly of section .text:

00000000100000e8 <.foobar>:
    100000e8:   fb e1 ff f8     std     r31,-8(r1)
    100000ec:   f8 21 ff c1     stdu    r1,-64(r1)
    100000f0:   7c 3f 0b 78     mr      r31,r1
    100000f4:   7c 69 1b 78     mr      r9,r3
    100000f8:   91 3f 00 70     stw     r9,112(r31)
    100000fc:   81 3f 00 70     lwz     r9,112(r31)
    10000100:   39 29 00 01     addi    r9,r9,1
    10000104:   7d 29 07 b4     extsw   r9,r9
    10000108:   7d 23 4b 78     mr      r3,r9
    1000010c:   38 3f 00 40     addi    r1,r31,64
    10000110:   eb e1 ff f8     ld      r31,-8(r1)
    10000114:   4e 80 00 20     blr
        ...
    10000120:   80 01 00 01     lwz     r0,1(r1)

If we build and objdump with gnu, but link with llvm, it doesn't seem to bring over the debug symbols:

$ powerpc64-linux-gnu-gcc -ffreestanding -O0 -c test.c -o test.ppc64.o
$ ld.lld --oformat=elf_ppc64 -nostdlib test.ppc64.o -o test.ppc64.elf
$ powerpc64-linux-gnu-objdump -d test.ppc64.elf

test.ppc64.elf:     file format elf64-powerpc

Disassembly of section .text:

0000000010010204 <.text>:
    10010204:   fb e1 ff f8     std     r31,-8(r1)
    10010208:   f8 21 ff c1     stdu    r1,-64(r1)
    1001020c:   7c 3f 0b 78     mr      r31,r1
    10010210:   7c 69 1b 78     mr      r9,r3
    10010214:   91 3f 00 70     stw     r9,112(r31)
    10010218:   81 3f 00 70     lwz     r9,112(r31)
    1001021c:   39 29 00 01     addi    r9,r9,1
    10010220:   7d 29 07 b4     extsw   r9,r9
    10010224:   7d 23 4b 78     mr      r3,r9
    10010228:   38 3f 00 40     addi    r1,r31,64
    1001022c:   eb e1 ff f8     ld      r31,-8(r1)
    10010230:   4e 80 00 20     blr
        ...
    1001023c:   80 01 00 01     lwz     r0,1(r1)

The same behavior happens if I build with clang targeting ppc64. Also, this all seems to work fine on ppc64le.

[llvmbot]

@llvm/issue-subscribers-backend-powerpc

Author: Aaron Simmons (paleozogt)

In #156704 I misunderstood where the problem was. Clang seems to be ok when cross-compiling for ppc64(be), but `ld.lld` and `llvm-objdump` have problems with debug symbols.

Given a simple c file:

// test.c
int foobar(int v) {
   return v+1;
}

Build and link with gnu, but objdump with llvm, which doesn't seem to know where the symbols are:

$ powerpc64-linux-gnu-gcc -ffreestanding -O0 -c test.c -o test.ppc64.o
$ powerpc64-linux-gnu-ld -nostdlib test.ppc64.o -o test.ppc64.elf
$ llvm-objdump-14 -d test.ppc64.elf

test.ppc64.elf: file format elf64-powerpc

Disassembly of section .text:

00000000100000e8 <.text>:
100000e8: fb e1 ff f8   std 31, -8(1)
100000ec: f8 21 ff c1   stdu 1, -64(1)
100000f0: 7c 3f 0b 78   mr      31, 1
100000f4: 7c 69 1b 78   mr      9, 3
100000f8: 91 3f 00 70   stw 9, 112(31)
100000fc: 81 3f 00 70   lwz 9, 112(31)
10000100: 39 29 00 01   addi 9, 9, 1
10000104: 7d 29 07 b4   extsw 9, 9
10000108: 7d 23 4b 78   mr      3, 9
1000010c: 38 3f 00 40   addi 1, 31, 64
10000110: eb e1 ff f8   ld 31, -8(1)
10000114: 4e 80 00 20   blr
                ...
10000120: 80 01 00 01   lwz 0, 1(1)

Contrast that with gnu's objdump behavior:

$ powerpc64-linux-gnu-objdump -d test.ppc64.elf

test.ppc64.elf:     file format elf64-powerpc

Disassembly of section .text:

00000000100000e8 <.foobar>:
    100000e8:   fb e1 ff f8     std     r31,-8(r1)
    100000ec:   f8 21 ff c1     stdu    r1,-64(r1)
    100000f0:   7c 3f 0b 78     mr      r31,r1
    100000f4:   7c 69 1b 78     mr      r9,r3
    100000f8:   91 3f 00 70     stw     r9,112(r31)
    100000fc:   81 3f 00 70     lwz     r9,112(r31)
    10000100:   39 29 00 01     addi    r9,r9,1
    10000104:   7d 29 07 b4     extsw   r9,r9
    10000108:   7d 23 4b 78     mr      r3,r9
    1000010c:   38 3f 00 40     addi    r1,r31,64
    10000110:   eb e1 ff f8     ld      r31,-8(r1)
    10000114:   4e 80 00 20     blr
        ...
    10000120:   80 01 00 01     lwz     r0,1(r1)

If we build and objdump with gnu, but link with llvm, it doesn't seem to bring over the debug symbols:

$ powerpc64-linux-gnu-gcc -ffreestanding -O0 -c test.c -o test.ppc64.o
$ ld.lld --oformat=elf_ppc64 -nostdlib test.ppc64.o -o test.ppc64.elf
$ powerpc64-linux-gnu-objdump -d test.ppc64.elf

test.ppc64.elf:     file format elf64-powerpc

Disassembly of section .text:

0000000010010204 <.text>:
    10010204:   fb e1 ff f8     std     r31,-8(r1)
    10010208:   f8 21 ff c1     stdu    r1,-64(r1)
    1001020c:   7c 3f 0b 78     mr      r31,r1
    10010210:   7c 69 1b 78     mr      r9,r3
    10010214:   91 3f 00 70     stw     r9,112(r31)
    10010218:   81 3f 00 70     lwz     r9,112(r31)
    1001021c:   39 29 00 01     addi    r9,r9,1
    10010220:   7d 29 07 b4     extsw   r9,r9
    10010224:   7d 23 4b 78     mr      r3,r9
    10010228:   38 3f 00 40     addi    r1,r31,64
    1001022c:   eb e1 ff f8     ld      r31,-8(r1)
    10010230:   4e 80 00 20     blr
        ...
    1001023c:   80 01 00 01     lwz     r0,1(r1)

The same behavior happens if I build with clang targeting ppc64. Also, this all seems to work fine on ppc64le.

[aabhinavg1]

I tried reproducing the issue with a minimal example:

// test.c
int foobar(int v) {
    return v + 1;
}

# Compile to object (freestanding, no libs)
powerpc64-linux-gnu-gcc -ffreestanding -O0 -c test.c -o test.ppc64.o

# Link into ELF, entry point = foobar
powerpc64-linux-gnu-ld -nostdlib test.ppc64.o -o test.ppc64.elf -e foobar

# Inspect symbols
readelf -s test.ppc64.elf | grep foobar
llvm-objdump -t test.ppc64.elf | grep foobar

# Disassemble with LLVM and GNU
llvm-objdump -d test.ppc64.elf
powerpc64-linux-gnu-objdump -d test.ppc64.elf

• The ELF symbol table shows foobar as a function in .opd
  (expected on PowerPC64 BE, which uses procedure descriptors).
• llvm-objdump -t sees the symbol.
• llvm-objdump -d shows <.text> instead of <foobar>.
• GNU objdump -d correctly resolves the .opd entry and displays <foobar>.
• The ELF itself is fine GCC and LD produce the correct symbols.
• The difference lies only in how the disassemblers label functions.

LLVM objdump does not fully handle PPC64 BE .opd procedure descriptors when labeling disassembly.
The symbols exist and are correct in the ELF, but LLVM does not map them back to function names, unlike GNU objdump.