cmd/link: unable to initialize decompress status for section .debug_info after Go 1.15.3 #42136
Comments
What is the GCC version that was used? |
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
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. |
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.) |
|
Sorry for taking up your time. |
Thanks for following up. |
Fortunately, I had the same problem with another similar project.
This is the file about folder. |
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:
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. |
What version of the C linker are you using? That is, what is the output of Also, what version of the C assembler are you using? What is the output of |
The above is relevant information, thanks for your help. |
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. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yep.
What operating system and processor architecture are you using (
go env
)?What did you do?
go test ./... ( go build also can occur )
What did you expect to see?
What did you see instead?
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.
The text was updated successfully, but these errors were encountered: