[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fe5cb7f94d4e9b6fc932017d4ee74ba4f9f417b9 commit r11-6893-gfe5cb7f94d4e9b6fc932017d4ee74ba4f9f417b9 Author: Jakub Jelinek Date: Mon Jan 25 14:20:05 2021 +0100 configure: Add workaround for buggy binutils 2.35 [PR98811] binutils since https://sourceware.org/bugzilla/show_bug.cgi?id=25612 changes from March last year until the https://sourceware.org/pipermail/binutils/2020-August/112684.html fix in early August emits incorrect .debug_info when assembling files with --gdwarf-5. Instead of emitting proper DWARF 5 .debug_info header, it emits DWARF 4 .debug_info header with 5 as the dwarf version instead of 4. This results e.g. in libgcc.a (morestack.o) having garbage in its .debug_info sections and e.g. libbacktrace during pretty much all libgo tests fails miserably. The following patch adds a workaround for that, don't set HAVE_AS_GDWARF_5_DEBUG_FLAG if readelf can't read the .debug_info back. Built tested on x86_64-linux against both binutils 2.35 (buggy ones) and latest binutils trunk, the former with the patch now has DWARF 3 .debug_line and DWARF 2 .debug_info in morestack.o, while the latter as before correct DWARF 5 .debug_line and .debug_info. 2021-01-25 Jakub Jelinek PR debug/98811 * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG): Only define if readelf -wi is able to read the emitted .debug_info back. * configure: Regenerated.
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||nickc at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- So, I've traced this to libgcc.a (morestack.o). When built against binutils 2.35, we assemble that with: /home/jakub/src/gcc/obj76/./gcc/xgcc -B/home/jakub/src/gcc/obj76/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -fchecking=1 -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o morestack.o -MT morestack.o -MD -MP -MF morestack.dep -c -xassembler-with-cpp -include morestack.vis ../../../libgcc/config/i386/morestack.S and that invokes gas with --gdwarf-5 option, as HAVE_AS_GDWARF_5_DEBUG_FLAG is defined (but HAVE_AS_WORKING_DWARF_N_FLAG is not because it doesn't contain the needed bugfixes). The line table looks sane, at least trunk binutils readelf is happy about it, and .debug_abbrev too: /usr/src/binutils-gdb/obj/binutils/readelf -wa morestack.o Contents of the .debug_abbrev section: Number TAG (0x0) 1 DW_TAG_compile_unit[no children] DW_AT_stmt_listDW_FORM_data4 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_data8 DW_AT_name DW_FORM_strp DW_AT_comp_dir DW_FORM_strp DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data2 DW_AT value: 0 DW_FORM value: 0 but .debug_info section is total garbage: /usr/src/binutils-gdb/obj/binutils/readelf -wi morestack.o Contents of the .debug_info section: readelf: Error: .debug_abbrev section not zero terminated readelf: Warning: Invalid pointer size (0) in compunit header, using 4 instead Compilation Unit @ offset 0x0: Length:0x2a (32-bit) Version: 5 Unit Type: ??? (0) Abbrev Offset: 0x108 Pointer Size: 4 readelf: Warning: CU at offset 0 contains corrupt or unsupported unit type: 0. eu-readelf --debug-dump=info morestack.o DWARF section [17] '.debug_info' at offset 0x2fa: [Offset] Compilation unit at offset 0: Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4 Unit type: ??? (0) (0) eu-readelf: unknown version (5) or unit type (0) So, I think we need to add a check that --gdwarf-5 actually works properly on assembly sources and not define HAVE_AS_GDWARF_5_DEBUG_FLAG otherwise. Minimal testcase: .text nop as --gdwarf-5 test.s -o test.o readelf -wi test.o Guess it would be nice to bisect which binutils change fixed this and write a reliable check. I'd think binutils 2.34 and earlier would be fine, as they wouldn't claim --gdwarf-5 support at all. If I with the buggy binutils do as --gdwarf-4 test.s -o test.o vs. as --gdwarf-5 test.s -o test.o and objdump -s -j .debug_info test.o in each case, the only difference between the two sections is the version 5 vs. 4 in the section. But DWARF5 .debug_info header is different between DWARF4 and DWARF5. So, my guess it is https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a3b3e8586d80204660e203d05edfe88418c394a2 aka https://sourceware.org/pipermail/binutils/2020-August/112684.html
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I can reproduce that on Fedora 33 too (but it works in the Fedora 34 builds where we have binutils 2.35.1 + various dwarf5 patches).
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #3 from Mark Wielaard --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > If the DWARF-5 support depends on specific binutils versions/patches to > work, this should both be documented and detected at configure time. > Having users run into such complete failure as in the Go case is a very > bad user experience IMO. I believe it already does. There are some known issues with debug_line generation that gcc configure should detect and disable if a bad/old binutils is detected. But given your experience there might be other bugs, but I don't which they are. If you know which binutils patch fixes it then we might be able to create a configure test for it.
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Mark Wielaard --- > (In reply to Rainer Orth from comment #0) >> However, when I switched to >> the freshly released GNU as 2.36 today, the error vanished everywhere. > > Which GNU as were you using before? There were some bug fixes for 2.35 which > never made it into a released version: > https://sourceware.org/pipermail/binutils/2020-November/114152.html The unmodified 2.35 release. I stick with self-compiled versions to avoid depending on distributions making their own set of changes. If the DWARF-5 support depends on specific binutils versions/patches to work, this should both be documented and detected at configure time. Having users run into such complete failure as in the Go case is a very bad user experience IMO.
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #1 from Mark Wielaard --- (In reply to Rainer Orth from comment #0) > However, when I switched to > the freshly released GNU as 2.36 today, the error vanished everywhere. Which GNU as were you using before? There were some bug fixes for 2.35 which never made it into a released version: https://sourceware.org/pipermail/binutils/2020-November/114152.html
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
