[PATCH] Linker: Replace overridden subprograms

[David Blaikie]

Should "OverridingFunctions" be "OverriddenFunctions"? (it looks like
everything in that set gets dropped from the subprogram lists - so if those
are the functions chosen to be kept by the linker, I would think that would
end up with them all being dropped from the debug info - the exact opposite
of what's desired - but I assume I'm misunderstanding something)

(stylistically I'd remove a bunch of the conditionals in that code as not
too important: if the function set is empty, everything else should be
fairly trivial, I don't necessarily know that the early return is
particularly valuable. Two calls to getNamedMetadata (& two checks of the
same non-null result). CUs in the CU list should never be null, the
subprogram array should never be null (I think that's the case?). & I might
even not bother with the old size != new size condition either - just to
keep the code simple/easy to read)

- David

On Tue, Dec 16, 2014 at 12:14 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
>
>
> > On 2014 Dec 16, at 10:27, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Tue, Dec 16, 2014 at 10:06 AM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> >
> > > 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)?
> >
> > 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)
> >
> >
> > If so, I can just do that.
>
> How does this look?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141216/b10a4f43/attachment.html>