[Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range

[Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811

            Bug ID: 98811
           Summary: [11 regression] All Go tests FAIL with abbrev offset
                    out of range
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: ian at airs dot com, mark at gcc dot gnu.org
  Target Milestone: ---
            Target: *-*-solaris2.11, i686-pc-linux-gnu,
                    x86_64-pc-linux-gnu

Since the switch to DWARF-5, all Go execution tests started to FAIL in the same
way:
fatal error: abbrev offset out of range

goroutine 1 [running, locked to thread]:
fatal error: abbrev offset out of range
panic during panic

goroutine 1 [running, locked to thread]:
fatal error: abbrev offset out of range
stack trace unavailable

I'm seeing this on both Solaris and Linux, 32 and 64-bit.  However, this does
not happen when Solaris as is in use, only with GNU as 2.35 (irrespective of
linker:
Solaris ld and GNU ld show the same behaviour).  However, when I switched to
the freshly released GNU as 2.36 today, the error vanished everywhere.

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[ro at gcc dot gnu.org]

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

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[mark at gcc dot gnu.org]

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

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[mark at gcc dot gnu.org]

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.

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[jakub at gcc dot gnu.org]

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).

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[jakub at gcc dot gnu.org]

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

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[cvs-commit at gcc dot gnu.org]

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.

[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range

[jakub at gcc dot gnu.org]

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.