<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 10:06 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 2014-Dec-16, at 10:00, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Dec 16, 2014 at 9:48 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
> > It's possible to put DWARF subprogram definitions for linkonce_odr functions<br>
> > into comdat groups so they are dropped along with the linkonce_odr function,<br>
> > but Clang (& I don't think GCC by default) does that (there's some overhead<br>
> > to that representational choice, etc). But yes, it can be done. I think<br>
> > today, for both GCC and Clang, you'd end up with two subprogram definitions<br>
> > (one in each DWARF compile unit) each pointing to the same high_pc/low_pc to<br>
> > describe the function.<br>
><br>
> I thought this was part of a special case for dwarf in linkers (and<br>
> the missing feature why lld produced binaries are much larger in -g<br>
> builds).<br>
><br>
> To the best of my knowledge, at least the usual Linux linkers (gold and binutils-ld) don't have any special cases for DWARF (well, gold has some magic to generate a GDB debug info index, maybe), it's just sections and relocations like any other data in an object file. /maybe/ dsymutil on MacOS does, but I've not heard about it. (& possibly dwz - a debug info-aware compression tool could do that trick, it's designed to eliminate redundancy in debug info)<br>
><br>
> A basic test case shows roughly what I described. (attached dwarfdump, if you're curious - you can see what the source would've looked like from the DWARF there (inline function in a header, two translation units that instantiate the inline function, etc))<br>
><br>
><br>
> > (but yeah, vaguely sounds like what you're suggesting would make sense - I<br>
> > haven't looked at the initial proposed patch yet, though)<br>
><br>
> Cheers,<br>
> Rafael<br>
</div></div>> <dump.txt><br>
<br>
Even if other linkers don't do it, is it reasonable to delete subprograms from<br>
compile units if the canonical one is from another compile unit (and has a<br>
subprogram there)?<br></blockquote><div><br>I think so - more importantly, I assume that's what we'll end up doing anyway. (check the actual DWARF output - since we build a map of subprograms, I don't think we end up emitting the subprogram to both CUs anyway - we just ignore all but the first one we find - that's my bet anyway)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If so, I can just do that.<br>
<br>
If not, is the original patch okay (as a stop-gap)?</blockquote><div><br> Probably, though the code seems somewhat complicated & I haven't quite managed to internalize it all.</div></div></div></div>