public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: "Martin Liška" <mliska@suse.cz>, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] elf: Don't load archive element after dynamic definition
Date: Wed, 2 Sep 2020 22:35:22 +0930	[thread overview]
Message-ID: <20200902130522.GI15695@bubble.grove.modra.org> (raw)
In-Reply-To: <CAMe9rOom7buSgwHfjzurEKEKg6qHLY-KrZtBGUgysbFsJ9_n0A@mail.gmail.com>

On Wed, Sep 02, 2020 at 04:56:48AM -0700, H.J. Lu wrote:
> On Wed, Sep 2, 2020 at 1:12 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Wed, Sep 02, 2020 at 08:52:06AM +0200, Martin Liška wrote:
> > > On 8/28/20 4:50 PM, H.J. Lu via Binutils wrote:
> > > > PR ld/26530 test still failed.
> > >
> > > Hello.
> > >
> > > Is there any progress on this please?
> >
> > I think what we want is the following, and some tweaking of the
> > testsuite to remove FAIL: PR ld/15146 (1).  That test relied on not
> > loading a shared lib due to an IR symbol reference, but the logic
> > added by git commit 3d5bef4c0871 has already been reverted.
> >
> > diff --git a/bfd/elflink.c b/bfd/elflink.c
> > index 5c085b14b7..346f534911 100644
> > --- a/bfd/elflink.c
> > +++ b/bfd/elflink.c
> > @@ -4977,11 +4977,7 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
> >              object and a shared object.  */
> >           bfd_boolean dynsym = FALSE;
> >
> > -         /* Plugin symbols aren't normal.  Don't set def_regular or
> > -            ref_regular for them, or make them dynamic.  */
> > -         if ((abfd->flags & BFD_PLUGIN) != 0)
> > -           ;
> > -         else if (! dynamic)
> > +         if (! dynamic)
> >             {
> >               if (! definition)
> >                 {
> > @@ -5162,10 +5158,6 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
> >               && !bfd_link_relocatable (info))
> >             dynsym = FALSE;
> >
> > -         /* Nor should we make plugin symbols dynamic.  */
> > -         if ((abfd->flags & BFD_PLUGIN) != 0)
> > -           dynsym = FALSE;
> > -
> >           if (definition)
> >             {
> >               h->target_internal = isym->st_target_internal;
> > @@ -5192,7 +5184,7 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
> >                 }
> >             }
> >
> > -         if (dynsym && h->dynindx == -1)
> > +         if (dynsym && (abfd->flags & BFD_PLUGIN) == 0 && h->dynindx == -1)
> >             {
> >               if (! bfd_elf_link_record_dynamic_symbol (info, h))
> >                 goto error_free_vers;
> 
> Will it add a shared library to DT_NEEDED even if the IR symbol reference is
> removed by LTO?

Yes.  That can't be helped.  I know we worried about unnecessary
--as-needed shared libraries in the past when IR symbols disappear
after LTO, but I can't see a simple and reliable way for the linker to
be correct.

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.

-- 
Alan Modra
Australia Development Lab, IBM

  reply	other threads:[~2020-09-02 13:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 17:28 H.J. Lu
2020-08-27 13:53 ` Alan Modra
2020-08-27 14:05   ` H.J. Lu
2020-08-28  1:58     ` Alan Modra
2020-08-28 12:53       ` H.J. Lu
2020-08-28 14:49         ` Alan Modra
2020-08-28 14:50           ` H.J. Lu
2020-09-02  6:52             ` Martin Liška
2020-09-02  8:12               ` Alan Modra
2020-09-02 11:56                 ` H.J. Lu
2020-09-02 13:05                   ` Alan Modra [this message]
2020-09-02 13:22                     ` H.J. Lu
2020-09-02 14:29                       ` Alan Modra
2020-09-02 14:35                         ` H.J. Lu
2020-09-03  1:31                           ` Alan Modra
2020-09-03  2:16                             ` H.J. Lu
2020-09-03  6:07                               ` Alan Modra
2020-09-03 11:34                                 ` H.J. Lu
2020-09-04  7:25                                   ` Alan Modra
2020-09-04 11:06                                     ` H.J. Lu
2020-09-08  5:42                                       ` Alan Modra
2020-09-08 12:43                                         ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200902130522.GI15695@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).