https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #14) > (In reply to Iain Sandoe from comment #13) > > (In reply to Iain Sandoe from comment #12) > > current trunk (271111), manual regeneration of the > firmware.elf.ltrans0.ltrans.o -> > > (it's kinda frustrating that one can't see the link line, more tweaks are > still needed to help debug LTO - but putting -Wl,--verbose indicates that > the right number of files are presented to, and load correctly) > > iains@gcc122:~/gcc-trunk/C$ ../../llvm-710-build/bin/llvm-dwarfdump --verify > firmware.elf.ltrans0.ltrans.o > Verifying firmware.elf.ltrans0.ltrans.o: file format ELF64-x86-64 > Verifying .debug_abbrev... > Verifying .debug_info Unit Header Chain... > Verifying .debug_info references... > error: invalid DIE reference 0x0000001d. Offset is in between DIEs: > > 0x00000038: DW_TAG_subprogram > DW_AT_abstract_origin (0x000000000000001d) > DW_AT_low_pc (0x0000000000000000) > DW_AT_high_pc (0x0000000000000000) > DW_AT_frame_base (DW_OP_call_frame_cfa) > DW_AT_GNU_all_call_sites (true) > > > error: invalid DIE reference 0x0000003b. Offset is in between DIEs: > > 0x0000004f: DW_TAG_variable > DW_AT_abstract_origin (0x000000000000003b) > DW_AT_location (DW_OP_addr 0x0) > > > Errors detected. Btw, this is quite natural if you inspect an object file! There are relocations for these "zero" values. And the final linked object looks fine in this regard. So throwing llvm-dwarfdump on an object file is a user error (or rather llvm-dwarfdump doesn't understand there can be relocations in DW_AT_abstract_origin for example).
