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

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.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