https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99606
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |10.3
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. Somehow the refs to the early debug which use DW_FORM_ref_addr
and relocs in .rela.debug_info like
00000000002a 00140000000a R_X86_64_32 0000000000000000 t.i.5afc35f3 + 7e
do not work with -gdwarf-5, but I see nothing wrong with the objects so this
must be a linker issue? Why would the linker even try to decode DWARF here? I
suppose BFD fails to pick up the correct .debug_abbrev for the abstract origin
DIE and instead tries to use the refering .debug_abbrev.
With ld 2.35.1 I get a different error btw:
> ./xgcc -B. -gdwarf-5 -Werror -O2 t.i -flto -g -v -save-temps
...
[Leaving LTRANS ./a.ltrans0.o]
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: DWARF
error: invalid abstract instance DIE ref
./a.ltrans0.ltrans.o: in function `main':
<artificial>:(.text.startup+0x1): undefined reference to `stack_size'
...
Maybe the BFD dwarf reader needed the import tags to pick up referenced CUs
(and their abbrevs).
I suppose the DWARF reads are triggered by the diagnostics (likewise for gold).
Maybe they are simply looking at unrelocated DWARF?
As said, this is a linker issue - the imports are technically not required.
