<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:i@maskray.me" title="Fangrui Song <i@maskray.me>"> <span class="fn">Fangrui Song</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - lld doesn't generate DW_MACRO_import like ld.bfd does, leading to gdb cpu/memory hog"
href="https://bugs.llvm.org/show_bug.cgi?id=42030">bug 42030</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>i@maskray.me
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>WONTFIX
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - lld doesn't generate DW_MACRO_import like ld.bfd does, leading to gdb cpu/memory hog"
href="https://bugs.llvm.org/show_bug.cgi?id=42030#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - lld doesn't generate DW_MACRO_import like ld.bfd does, leading to gdb cpu/memory hog"
href="https://bugs.llvm.org/show_bug.cgi?id=42030">bug 42030</a>
from <span class="vcard"><a class="email" href="mailto:i@maskray.me" title="Fangrui Song <i@maskray.me>"> <span class="fn">Fangrui Song</span></a>
</span></b>
<pre>% 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
<a href="http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_groups">http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_groups</a> ,
such relocations to .Ldebug_macro should not be allowed.
<span class="quote">> 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.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>