* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
@ 2021-01-24 21:25 ` ro at gcc dot gnu.org
2021-01-24 21:33 ` mark at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ro at gcc dot gnu.org @ 2021-01-24 21:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
2021-01-24 21:25 ` [Bug debug/98811] " ro at gcc dot gnu.org
@ 2021-01-24 21:33 ` mark at gcc dot gnu.org
2021-01-24 21:55 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mark at gcc dot gnu.org @ 2021-01-24 21:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #1 from Mark Wielaard <mark at gcc dot gnu.org> ---
(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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
2021-01-24 21:25 ` [Bug debug/98811] " ro at gcc dot gnu.org
2021-01-24 21:33 ` mark at gcc dot gnu.org
@ 2021-01-24 21:55 ` ro at CeBiTec dot Uni-Bielefeld.DE
2021-01-24 22:12 ` mark at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2021-01-24 21:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Mark Wielaard <mark at gcc dot gnu.org> ---
> (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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
` (2 preceding siblings ...)
2021-01-24 21:55 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2021-01-24 22:12 ` mark at gcc dot gnu.org
2021-01-25 9:47 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mark at gcc dot gnu.org @ 2021-01-24 22:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #3 from Mark Wielaard <mark at gcc dot gnu.org> ---
(In reply to ro@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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
` (3 preceding siblings ...)
2021-01-24 22:12 ` mark at gcc dot gnu.org
@ 2021-01-25 9:47 ` jakub at gcc dot gnu.org
2021-01-25 11:15 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-25 9:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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).
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
` (4 preceding siblings ...)
2021-01-25 9:47 ` jakub at gcc dot gnu.org
@ 2021-01-25 11:15 ` jakub at gcc dot gnu.org
2021-01-25 13:20 ` cvs-commit at gcc dot gnu.org
2021-01-26 15:15 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-25 11:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com,
| |nickc at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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_list DW_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: 0x1080000
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
` (5 preceding siblings ...)
2021-01-25 11:15 ` jakub at gcc dot gnu.org
@ 2021-01-25 13:20 ` cvs-commit at gcc dot gnu.org
2021-01-26 15:15 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-25 13:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:fe5cb7f94d4e9b6fc932017d4ee74ba4f9f417b9
commit r11-6893-gfe5cb7f94d4e9b6fc932017d4ee74ba4f9f417b9
Author: Jakub Jelinek <jakub@redhat.com>
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 <jakub@redhat.com>
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
2021-01-24 21:25 [Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range ro at gcc dot gnu.org
` (6 preceding siblings ...)
2021-01-25 13:20 ` cvs-commit at gcc dot gnu.org
@ 2021-01-26 15:15 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-26 15:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 9+ messages in thread