[PATCH] Linker: Replace overridden subprograms

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Dec 16 10:06:01 PST 2014


> On 2014-Dec-16, at 10:00, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Dec 16, 2014 at 9:48 AM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
> > It's possible to put DWARF subprogram definitions for linkonce_odr functions
> > into comdat groups so they are dropped along with the linkonce_odr function,
> > but Clang (& I don't think GCC by default) does that (there's some overhead
> > to that representational choice, etc). But yes, it can be done. I think
> > today, for both GCC and Clang, you'd end up with two subprogram definitions
> > (one in each DWARF compile unit) each pointing to the same high_pc/low_pc to
> > describe the function.
> 
> I thought this was part of a special case for dwarf in linkers (and
> the missing feature why lld produced binaries are much larger in -g
> builds).
> 
> 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)
> 
> 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))
>  
> 
> > (but yeah, vaguely sounds like what you're suggesting would make sense - I
> > haven't looked at the initial proposed patch yet, though)
> 
> Cheers,
> Rafael
> <dump.txt>

Even if other linkers don't do it, is it reasonable to delete subprograms from
compile units if the canonical one is from another compile unit (and has a
subprogram there)?

If so, I can just do that.

If not, is the original patch okay (as a stop-gap)?



More information about the llvm-commits mailing list