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
