[PATCH] Linker: Replace overridden subprograms

[David Blaikie]

On Tue, Dec 16, 2014 at 7:23 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
>
> On 16 December 2014 at 01:20, Duncan P. N. Exon Smith
> <dexonsmith at apple.com> wrote:
> > When a function gets replaced by `ModuleLinker`, ensure that the "first"
> > subprogram pointing to it is updated to be the *same* subprogram pointed
> > to by the `!dbg` references in that function.  That means it should come
> > from the "first" subprogram in a linked-in compile unit.
> >
> > This is a stop-gap "fix" for PR21910.  Ideally we wouldn't have two
> > different subprograms around, but it's not easy to fix that.  In the
> > meantime, this fixes bootstraps that hit assertions in
> > `LexicalScopes::initialize()` due to the explicit instantiations in
> > `lib/IR/Dominators.cpp` eventually getting replaced by -argpromotion.
>
> The final objective is to delete the subprogram that was in the
> destination, correct? If I understand correctly, that is what regular

linkers do. They will keep the dwarf corresponding to the symbol they
> kept.
>

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.

(but yeah, vaguely sounds like what you're suggesting would make sense - I
haven't looked at the initial proposed patch yet, though)


> Can't you do just that? Before doing the rest of
> ModuleLinker::linkNamedMDNodes:
>
> * Record in a set the source functions that replaced some destination
> function.
> * Get llvm.dbg.cu of the destination module.
> * For each CU, get the list of subprograms.
> * Remove from the list any subprogram that points to one of the
> functions in the set.
>
> Also, should drop subprograms from the source that point to functions
> that were not copied over? Once module owns metadata we should not
> even copy those.
>
> With both of those done, the existing linkNamedMDNodes should finish
> up the work correctly, no?
>
> Is there a corresponding problem for global variables?
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141216/0df08fb0/attachment.html>