Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: dwarf compression broke mips builder #25939

Closed
josharian opened this issue Jun 18, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@josharian
Copy link
Contributor

commented Jun 18, 2018

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

@josharian josharian added this to the Go1.11 milestone Jun 18, 2018

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

This comment has been minimized.

Copy link

commented Jun 18, 2018

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

@gopherbot gopherbot closed this in 17a4e04 Jun 18, 2018

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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?

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2018

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.

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2018

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

@thanm

This comment has been minimized.

Copy link
Member

commented Jun 20, 2018

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.

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.