https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
Bug ID: 91239 Summary: gcc generates invalid .debug_macro sections (according to lld folks) Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, After a bug report opened to lld here https://bugs.llvm.org/show_bug.cgi?id=42030, lld folks rejected it as invalid based on the reason that apparently .debug_macro sections generated by gcc don't see valid. I am quoting them here, you can see my initial bug report to check what was my initial problem: <<END_OF_QUOTE ==================================== Fangrui Song 2019-06-30 23:04:00 PDT ==================================== % readelf --debug-dump=macro exe.bfd | grep 'DW_MACRO_import .* : 0x0' | wc -l 0 % readelf --debug-dump=macro exe.lld | grep 'DW_MACRO_import .* : 0x0' | wc -l 1185 gcc -g3 or -ggdb3 generates .debug_macro sections. # I think gcc/dwarf2out.c optimize_macinfo_range is responsible for the behavior. .section .debug_macro,"",@progbits ... .byte 0x7 # DW_MACRO_import .long .Ldebug_macro57 # relocation to a section symbol that may be in a discarded comdat .section .debug_macro,"G",@progbits,wm4.stl_tree.h.59.e99bfd6fdb0e5d5124d05bd97b997689,comdat .Ldebug_macro105: .Ldebug_macro105 is defined in .debug_macro which is in a comdat group called "wm4.stl_tree.h.xxxxxxxxxx". Other object files may define sections in the same comdat group. When these files are linked together, only the first comdat group is kept and the rest are discarded. .debug_macro,"",@progbits is not in a comdat group so the question is how to resolve .long .Ldebug_macro57 According to http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_groups , such relocations to .Ldebug_macro should not be allowed. > A symbol table entry with STB_LOCAL binding that is defined relative to one > of a group's sections, and that is contained in a symbol table section that > is not part of the group, must be discarded if the group members are > discarded. References to this symbol table entry from outside the group are > not allowed. I think ld.bfd/gold/lld error if the section containing the relocation is SHF_ALLOC. .debug* do not have the SHF_ALLOC flag and those relocations are allowed. lld resolves such relocations to 0. ld.bfd and gold, however, have some CB_PRETEND/PRETEND logic to resolve relocations to the definitions in the prevailing comdat groups. The code is hacky and may not suit lld. I think the proper fix of this problem is to patch gdb to ignore 0 DW_MACRO_import. ===================================== Paul Robinson 2019-07-01 06:30:34 PDT ===================================== If references to comdats aren't being emitted correctly, that seems like a compiler problem not a linker or debugger problem. This has the feel of bfd/gold working around a gcc issue. END_OF_QUOTE I am not sure to understand what they mean, I hope it's clearer for you ;) Cheers, Romain