cmd/link: dwarf compression broke mips builder

[josharian]

Starting with https://go-review.googlesource.com/c/go/+/118276, the mips builder is red.

[heschi]

Sigh. I watched the builders, but I guess not for long enough.

As best as I can tell, this is a bug in GDB on the mips builder. I built a binary on a mips gomote. On mips, GDB fails to read it, but readelf works fine. And everything I try (gdb, readelf, dwarfdump) on my amd64 workstation is happy too.

@ianlancetaylor, I think you're somewhat familiar with libbfd, any guesses as to what's going on here? Invalid operation is bfd_error_invalid_operation, which probably means an error in bfd_get_section_contents, but I don't see anything in that that should be architecture-sensitive.

        BFD: /tmp/go-build223566295/a.exe: unable to initialize decompress status for section .zdebug_abbrev
        "/tmp/go-build223566295/a.exe": not in executable format: Invalid operation

I think I'll just skip the test on mips?

[gopherbot]

Change https://golang.org/cl/119539 mentions this issue: runtime: skip gdb tests on mips after DWARF compression

[ianlancetaylor]

bfd_error_invalid_operation tells you nothing useful, it just means "something failed." The gdb error means that the file is in some format that BFD doesn't recognize. If you want to look into this more, what does objdump -f print for the "file format" on the executable that gdb won't open? If objdump fails, what does readelf -h print?

[heschi]

objdump -f:

tmp/hello:     file format elf32-tradbigmips
architecture: mips:isa32, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0006da10

readelf -e:

ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x6da10
  Start of program headers:          52 (bytes into file)
  Start of section headers:          276 (bytes into file)
  Flags:                             0x50001004, cpic, o32, mips32
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         24
  Section header string table index: 3
Section Headers:

[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

[ 0]                   NULL            00000000 000000 000000 00      0   0  0

[ 1] .text             PROGBITS        00011000 001000 091fb8 00  AX  0   0  4

[ 2] .rodata           PROGBITS        000b0000 0a0000 038768 00   A  0   0 32

[ 3] .shstrtab         STRTAB          00000000 0d8780 000193 00      0   0  1

[ 4] .typelink         PROGBITS        000e8920 0d8920 000b14 00   A  0   0 32

[ 5] .itablink         PROGBITS        000e9434 0d9434 000020 00   A  0   0  4

[ 6] .gosymtab         PROGBITS        000e9454 0d9454 000000 00   A  0   0  1

[ 7] .gopclntab        PROGBITS        000e9460 0d9460 0582fd 00   A  0   0 32

[ 8] .noptrdata        PROGBITS        00150000 140000 00c73c 00  WA  0   0 32

[ 9] .data             PROGBITS        0015c740 14c740 0058b0 00  WA  0   0 32

[10] .bss              NOBITS          00162000 152000 00f5f4 00  WA  0   0 32

[11] .noptrbss         NOBITS          00171600 161600 002468 00  WA  0   0 32

[12] .zdebug_abbrev    PROGBITS        00180000 160000 00010e 00      0   0  4

[13] .zdebug_line      PROGBITS        0018010e 16010e 00e1b1 00      0   0  4

[14] .zdebug_frame     PROGBITS        0018e2bf 16e2bf 004859 00      0   0  4

[15] .zdebug_pubnames  PROGBITS        00192b18 172b18 002783 00      0   0  4

[16] .zdebug_pubtypes  PROGBITS        0019529b 17529b 0026b2 00      0   0  4

[17] .debug_gdb_script PROGBITS        0019794d 17794d 00002a 00      0   0  1

[18] .zdebug_info      PROGBITS        00197977 177977 026e15 00      0   0  4

[19] .zdebug_loc       PROGBITS        001be78c 19e78c 00c7bd 00      0   0  4

[20] .zdebug_ranges    PROGBITS        001caf49 1aaf49 004336 00      0   0  4

[21] .note.go.buildid  NOTE            00010f9c 000f9c 000064 00   A  0   0  4

[22] .symtab           SYMTAB          00000000 1b0000 00bce0 10     23 107  4

[23] .strtab           STRTAB          00000000 1bbce0 011b7a 00      0   0  1

Key to Flags:

W (write), A (alloc), X (execute), M (merge), S (strings)

I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)

O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:

Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

PHDR           0x000034 0x00010034 0x00010034 0x000e0 0x000e0 R   0x10000

NOTE           0x000f9c 0x00010f9c 0x00010f9c 0x00064 0x00064 R   0x4

LOAD           0x000000 0x00010000 0x00010000 0x92fb8 0x92fb8 R E 0x10000

LOAD           0x0a0000 0x000b0000 0x000b0000 0x9175d 0x9175d R   0x10000

LOAD           0x140000 0x00150000 0x00150000 0x12000 0x23a68 RW  0x10000

GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

LOOS+5041580   0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4
Section to Segment mapping:

Segment Sections...

00

01     .note.go.buildid

02     .text .note.go.buildid

03     .rodata .shstrtab .typelink .itablink .gosymtab .gopclntab

04     .noptrdata .data .bss .noptrbss

05

06

[ianlancetaylor]

Thanks. Unfortunately I don't see anything. It's somewhat surprising that objdump works if gdb fails in this way. I don't know what is going on.

[heschi]

Thanks, all the other architectures are fine so I'm not inclined to stress about it.

[thanm]

For what it is worth, attaching output from dumping an object compiled with "clang --target=mips-linux -c -g -gz=zlib-gnu". One difference is that the dwarf section types are MIPS_DWARF and not PROGBITS (no idea whether that actually matters).

readelf -e:

ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          2188 (bytes into file)
  Flags:                             0x70001005, noreorder, cpic, o32, mips32r2
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 1
Section Headers:

[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

[ 0]                   NULL            00000000 000000 000000 00      0   0  0

[ 1] .strtab           STRTAB          00000000 000770 00011c 00      0   0  1

[ 2] .text             PROGBITS        00000000 000040 0000cc 00  AX  0   0 16

[ 3] .rel.text         REL             00000000 000658 000020 08     27   2  4

[ 4] .mdebug.abi32     PROGBITS        00000000 00010c 000000 00      0   0  1

[ 5] .pdr              PROGBITS        00000000 00010c 000040 00      0   0  4

[ 6] .rel.pdr          REL             00000000 000678 000010 08     27   5  4

[ 7] .zdebug_str       MIPS_DWARF      00000000 00014c 0000ae 01  MS  0   0  1

[ 8] .zdebug_abbrev    MIPS_DWARF      00000000 0001fa 000092 00      0   0  1

[ 9] .zdebug_info      MIPS_DWARF      00000000 00028c 000096 00      0   0  1

[10] .rel.zdebug_info  REL             00000000 000688 0000b0 08     27   9  4

[11] .debug_ranges     MIPS_DWARF      00000000 000322 000000 00      0   0  1

[12] .debug_macinfo    MIPS_DWARF      00000000 000322 000001 00      0   0  1

[13] .debug_pubnames   MIPS_DWARF      00000000 000323 000026 00      0   0  1

[14] .rel.debug_pubnam REL             00000000 000738 000008 08     27  13  4

[15] .zdebug_pubtypes  MIPS_DWARF      00000000 000349 00004c 00      0   0  1

[16] .rel.zdebug_pubty REL             00000000 000740 000008 08     27  15  4

[17] .comment          PROGBITS        00000000 000395 000038 01  MS  0   0  1

[18] .note.GNU-stack   PROGBITS        00000000 0003cd 000000 00      0   0  1

[19] .data             PROGBITS        00000000 0003d0 000000 00  WA  0   0 16

[20] .bss              NOBITS          00000000 0003d0 000000 00  WA  0   0 16

[21] .reginfo          MIPS_REGINFO    00000000 0003d0 000018 18   A  0   0  4

[22] .MIPS.abiflags    MIPS_ABIFLAGS   00000000 0003e8 000018 18   A  0   0  8

[23] .debug_frame      MIPS_DWARF      00000000 000400 00004c 00      0   0  4

[24] .rel.debug_frame  REL             00000000 000748 000020 08     27  23  4

[25] .debug_line       MIPS_DWARF      00000000 00044c 00007b 00      0   0  1

[26] .rel.debug_line   REL             00000000 000768 000008 08     27  25  4

[27] .symtab           SYMTAB          00000000 0004c8 000190 10      1  23  4

Key to Flags:

W (write), A (alloc), X (execute), M (merge), S (strings), I (info),

L (link order), O (extra OS processing required), G (group), T (TLS),

C (compressed), x (unknown), o (OS specific), E (exclude),

p (processor specific)
There are no program headers in this file.

[heschi]

That's interesting but I don't get why objdump would be inconsistent about it depending on the host platform. I'm gonna wait for someone who actually has access to a mips machine to complain about this; working with gomote is pretty painful.