[PATCH] elf: Don't load archive element after dynamic definition

[H.J. Lu]

On Wed, Sep 2, 2020 at 11:07 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Sep 02, 2020 at 07:16:14PM -0700, H.J. Lu wrote:
> > On Wed, Sep 2, 2020 at 6:31 PM Alan Modra <amodra@gmail.com> wrote:
> > >
> > > On Wed, Sep 02, 2020 at 07:35:58AM -0700, H.J. Lu wrote:
> > > > On Wed, Sep 2, 2020 at 7:29 AM Alan Modra <amodra@gmail.com> wrote:
> > > > >
> > > > > On Wed, Sep 02, 2020 at 06:22:08AM -0700, H.J. Lu wrote:
> > > > > > > It's reasonably obvious that we need to load archive elements when
> > > > > > > they define IR referenced symbols, because the archive element might
> > > > > > > be an LTO object.  What's not so obvious is whether loading of shared
> > > > > > > libraries should follow the same rule.  I think they should, in order
> > > > > > > for LTO to get symbol resolution correct in corner cases.  Basically
> > > > > > > LTO needs to know what shared libraries are loaded before
> > > > > > > recompilation.  See commit a896df97b952 log comments.
> > > > > >
> > > > > > There is dynamic_def for this purpose.
> > > > >
> > > > > Your patch doesn't make changes to ld/plugin.c to inform LTO of the
> > > > > availability of these symbols.  And if you did, then how does the
> > > > > linker work out whether or not the LTO recompilation depended on those
> > > > > symbols?  If it did change LTO recompilation then you had better
> > > > > ensure the library really is loaded.  By the time you work all of that
> > > > > out, if it is even possible, your patch will likely be very
> > > > > complicated indeed.
> > > >
> > > > A testcase?
> > >
> > > What don't you understand from my emails in this thread?  I suggest
> > > you look at what happened with the testcase in PR26314, in regard to
> > > my comment
> > >     The lto recompilation didn't see symbol references from libbfd.so and
> > >     variables like _xexit_cleanup are made local in the recompiled
> > >     objects.  Oops, two copies of them.
> >
> > A testcase?
>
> You kindly provided it yourself.
> https://sourceware.org/bugzilla/show_bug.cgi?id=26314#c4
>
> It takes only a small amount of digging to see the _xexit_cleanup
> problem.

This particular problem came from:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385

where GCC generated incorrect output and I do have a mitigation
patch.

-- 
H.J.