cmd/link: unable to initialize decompress status for section .debug_info after Go 1.15.3

[xiekeyi98]

What version of Go are you using (go version)?

before ` go version go1.15.2 linux/amd64 `
after `go version go1.15.3 linux/amd64`

Does this issue reproduce with the latest release?

yep.

What operating system and processor architecture are you using (go env)?

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/keyixie/.cache/go-build"
GOENV="/home/keyixie/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/keyixie/dev/pkg/mod"
GONOPROXY="git.code.oa.com"
GONOSUMDB="git.code.oa.com"
GOOS="linux"
GOPATH="/home/keyixie/dev"
GOPRIVATE="git.code.oa.com"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/keyixie/go/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/keyixie/go/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/keyixie/dev/src/git.code.oa.com/iotvideo_appuser/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build034162450=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go test ./... ( go build also can occur )

What did you expect to see?

What did you see instead?

---

/home/keyixie/go/go1.15.3/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/bin/ld: /tmp/go-link-815997864/000005.o: unable to initialize decompress status for section .debug_info
/bin/ld: /tmp/go-link-815997864/000005.o: unable to initialize decompress status for section .debug_info
/tmp/go-link-815997864/000005.o: file not recognized: 不可识别的文件格式
collect2: 错误：ld 返回 1

---

I'm sorry I haven't found a code snippet that reproduces reliably yet.
I would like to know if anyone has reported similar problems?
If there is anything I can help with for confirmation, I will add further information later.

[dmitshur]

CC @ianlancetaylor, @cherrymui.

[dmitshur]

running gcc failed

What is the GCC version that was used?

[thanm]

Seems pretty surprising-- between Go 1.15.2 and Go 1.15.3 I don't see any changes related to DWARF generation or linker DWARF compression.

不可识别的文件格式 is "unrecognized file format" -- that says that the header was bad for the compressed section I think.

Something that is also a puzzle is that "go test" builds with "-w", meaning that there should not be any DWARF generated at all (compressed or not). Hmm.

One thing that would help diagnose this: rerun your "go test" with additional options to capture the temporary object files, then run dump the DWARF in the offending file. Something like

$ mkdir /tmp/xxx
$ go test -ldflags=-tmpdir=/tmp/xxx  [... remaining 'go test' options ]

Then when you get the "/bin/ld: /tmp/xxx/000005.o: unable to initialize decompress status for section .debug_info" error, try running

$ objdump --dwarf=info /tmp/xxx/000005.o | egrep '(DW_AT_producer|DW_AT_name)' | head -5

That might tell us more about where the offending DWARF is coming from.

[cherrymui]

I think files like 000005.o is not an object file from Go code. It is an object file from C code (handwritten or cgo generated). (That's why it has debug info even when -w is applied.)

[xiekeyi98]

running gcc failed

What is the GCC version that was used?

gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[xiekeyi98]

Sorry for taking up your time.
Unfortunately, due to /tmp being cleaned up, I didn't succeed in reproduce it again.
I'm guessing it has something to do with cgo or the history file in /tmp.
I closed the issue for now and will reopen it if I got it again.
Thank you all for your help and tips.

[ianlancetaylor]

Thanks for following up.

[xiekeyi98]

Fortunately, I had the same problem with another similar project.

objdump --dwarf=info ./000000.o | egrep '(DW_AT_producer|DW_AT_name)' | head -5
objdump: ./000000.o: unable to initialize decompress status for section .debug_info
objdump: ./000000.o: unable to initialize decompress status for section .debug_info
objdump: ./000000.o: File format not recognized

This is the file about folder.
bugReport.zip

[thanm]

Thanks for posting the zip'ed folder with the intermediates.

For the record, when I run objdump (from my Debian work machine) on the object file from the zip file, it doesn't seem to have any problems with it:

$ objdump --dwarf=info ./000000.o | egrep '(DW_AT_producer|DW_AT_name)' | head -5
    <c>   DW_AT_producer    : (indirect string, offset: 0x8b): GNU C 4.8.5 20150623 (Red Hat 4.8.5-39)
    <11>   DW_AT_name        : (indirect string, offset: 0xd9): _cgo_export.c
...

In addition, looking at the object file itself, I don't see any compressed debug-- so this looks to me like some sort of problem with the binutils tools (objdump, ld) on your system.

As @cherrymui pointed out, the object file in question is being produced by gcc, and the error is triggered when the object file is read by the system linker (/bin/ld), so it does not seem at all clear that this is a problem with Go.

[ianlancetaylor]

What version of the C linker are you using? That is, what is the output of /bin/ld --version?

Also, what version of the C assembler are you using? What is the output of as --version? You may be running into https://sourceware.org/bugzilla/show_bug.cgi?id=23919.

[xiekeyi98]

md5sum ./000000.o 
658185dc80a44dada9ded0b003d6b208  ./000000.o

/bin/ld --version
GNU ld version 2.27-41.base.tl2.1
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.


as --version
GNU assembler version 2.27-41.base.tl2.1
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-redhat-linux'.


gcc --version                                 
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The above is relevant information, thanks for your help.
I wonder if it's because I have a special version of linux (https://github.com/Tencent/TencentOS-kernel#tencentos-server-kernel), it's a GNU related bug, not golang related.

[ianlancetaylor]

Yes, I think this is a bug that was fixed in GNU binutils 2.32, and you are running 2.27.

Closing because I don't think this is a bug that we can fix in Go. Please comment if you disagree.