public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Alan Modra <amodra@gmail.com>,  Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] elf: Don't set VER_FLG_WEAK
Date: Mon, 31 Jan 2022 17:47:57 +0100	[thread overview]
Message-ID: <87k0ef7sxu.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAMe9rOpwRavqZN4sT8CqY=7wN-cMegmuA4=Apc6i0N4f4ZB0Pg@mail.gmail.com> (H. J. Lu's message of "Wed, 26 Jan 2022 05:26:34 -0800")

* H. J. Lu:

> On Tue, Jan 25, 2022 at 7:07 PM Alan Modra <amodra@gmail.com> wrote:
>>
>> On Tue, Jan 25, 2022 at 04:19:53PM -0800, H.J. Lu via Binutils wrote:
>> > On Solaris, VER_FLG_WEAK indicates a weak version definition with no
>> > symbols associated with it.  It is used to verify the existence of a
>> > particular implementation without any symbol references to the weak
>> > version.  Don't set VER_FLG_WEAK since it is unused in binutils.
>>
>> Can you tell me why the presence of this flag is bad?  I don't see it
>> affecting anything in binutils or glibc.  VER_FLG_WEAK in version refs
>> does affect resolution of symbol, but I can't see how a VER_FLG_WEAK
>> in a version def can transfer over to a ref if the def is unused.
>
> Florian,  can you share the reason why Linux doesn't want
> VER_FLG_WEAK on the empty version?

I may have been overly cautious, influenced by the old link editor
behavior which copied the weak flag of dynamic symbols from the
definitions to their references.  But it's indeed unclear how this could
happen here.  If it did, we would lose the coverage check in the glibc
dynamic loader for that symbol version, I think.  (The loader only
checks vna_flags in two places, once for printing the flag, and once to
skip an error report in case of a missing version.)

Do you suggest we should start using weak symbol version definitions in
glibc, and not worry about it?

Thanks,
Florian


  reply	other threads:[~2022-01-31 16:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26  0:19 H.J. Lu
2022-01-26  3:07 ` Alan Modra
2022-01-26 13:26   ` H.J. Lu
2022-01-31 16:47     ` Florian Weimer [this message]
2022-01-31 18:19       ` H.J. Lu
2022-02-01  8:44 Nick Clifton

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=87k0ef7sxu.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /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).