public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Fangrui Song <i@maskray.me>, Nick Clifton <nickc@redhat.com>,
	Alan Modra <amodra@gmail.com>
Cc: Binutils <binutils@sourceware.org>,
	Andreas Schwab <schwab@linux-m68k.org>
Subject: PING: V4 [PATCH] gas: Extend .symver directive
Date: Mon, 20 Apr 2020 07:03:33 -0700	[thread overview]
Message-ID: <CAMe9rOo84x2aBf89VUg52T-uQ3xDyL_iWuap-x4b=19EnPHBhA@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOoFnO=B3+56UYouXnvxC2foCjKtQ7ACGzo5q1EroDoSYA@mail.gmail.com>

On Sat, Apr 11, 2020 at 7:22 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Apr 9, 2020 at 10:16 AM Fangrui Song <i@maskray.me> wrote:
> >
> > On 2020-04-08, H.J. Lu wrote:
> > >On Wed, Apr 8, 2020 at 5:53 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >>
> > >> On Tue, Apr 7, 2020 at 4:58 PM Fangrui Song <i@maskray.me> wrote:
> > >> >
> > >> > On 2020-04-07, H.J. Lu wrote:
> > >> > >On Tue, Apr 7, 2020 at 2:23 PM Fangrui Song <i@maskray.me> wrote:
> > >> > >>
> > >> > >> On 2020-04-07, H.J. Lu via Binutils wrote:
> > >> > >> >On Tue, Apr 7, 2020 at 5:55 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> > >> > >> >>
> > >> > >> >> On Apr 07 2020, H.J. Lu wrote:
> > >> > >> >>
> > >> > >> >> > The optional argument VISIBILITY updates the visibility of
> > >> > >> >> > the original symbol.  The valid visibilities are 'local', 'hidden', and
> > >> > >> >> > 'remove'.  The 'local' visibility makes the original symbol a local
> > >> > >> >> > symbol (*note Local::).  The 'hidden' visibility sets the visibility of
> > >> > >> >> > the original symbol to 'hidden' (*note Hidden::).  The 'remove'
> > >> > >> >> > visibility removes the original symbol from the symbol table.  If
> > >> > >> >> > visibility isn't specified, the original symbol is unchanged.
> > >> > >> >>
> > >> > >> >> Looks good.
> > >> > >> >
> > >> > >> >Here is the updated patch.
> > >> > >> >
> > >> > >> >--
> > >> > >> >H.J.
> > >> > >>
> > >> > >> Let me summarize the current status:
> > >> > >>
> > >> > >> @@@ has the renaming semantics. (invented in 2000)
> > >> > >> @ and @@ has the copying semantics. The original symbol remains which is usually cumbersome.
> > >> > >>
> > >> > >> We have received some requests:
> > >> > >>
> > >> > >> * Have a way to not retain the original symbol
> > >> > >> * Have a way to define multiple versions `.symver something,foo@v1; .symver something,foo@v2. symver something,foo@@v3`
> > >> > >>
> > >> > >>
> > >> > >> We have many choices.
> > >> > >>
> > >> > >> A. make @ @@ similar to @@@
> > >> > >>    For @@, because of the linking rule (a @@ definition can satisfy a
> > >> > >>    referenced without a version), there should be no difference.
> > >> > >>
> > >> > >>    For @, this will be a semantic break. Personally I don't think this
> > >> > >>    matters. I believe 99% projects don't need the original symbol and
> > >> > >>    will not notice anything. I also checked with FreeBSD developers.
> > >> > >
> > >> > >The original symbol name is used in glibc to bypass PLT within
> > >> > >libc.so.
> > >> >
> > >> > This does not seem correct. By convention, the hidden aliases are those prefixed with __
> > >> > They are called to bypass PLT (STV_HIDDEN implies the non-preemptible property).
> > >> > The original symbol does not have the prefix.
> > >> >
> > >> > When a linker sees memcpy@@GLIBC_2.14 , basically it inserts both "memcpy" and
> > >> > "memcpy@GLIBC_2.14" into the symbol table.  Both a reference without a version
> > >> > "memcpy" and a reference with a version "memcpy@GLIBC_2.14" can be satisfied.
> > >>
> > >> As I said before, the original purpose of .symver is for glibc to
> > >> implement symbol
> > >> versioning.  Given:
> > >>
> > >> ---
> > >> const int _sys_nerr_internal = 200;
> > >> __asm__ (".symver _sys_nerr_internal, sys_nerr@@GLIBC_2.12");
> > >> ---
> > >>
> > >> _sys_nerr_internal is used internally in glibc:
> > >>
> > >> File: libc_pic.a(_strerror.os)
> > >>
> > >> Relocation section '.rela.text' at offset 0x14e0 contains 17 entries:
> > >>     Offset             Info             Type               Symbol's
> > >> Value  Symbol's Name + Addend
> > >> 000000000000001c  0000001500000002 R_X86_64_PC32
> > >> 0000000000000000 _sys_nerr_internal - 4
> > >> 000000000000002c  0000001600000002 R_X86_64_PC32
> > >> 0000000000000000 _sys_errlist_internal - 4
> > >>
> > >> ---
> > >> char *
> > >> __strerror_r (int errnum, char *buf, size_t buflen)
> > >> {
> > >>   ...
> > >>   return (char *) _(_sys_errlist_internal[errnum]);
> > >> }
> > >> ---
> > >>
> > >> Also with -g, _sys_nerr_internal is also referenced in debug info.  We
> > >> just can't change .symver to rename.
> >
> > OK.
> >
> > >> > If the definition of "memcpy" also exists, I think it is somewhat special cased
> > >> > in GNU ld and/or gold. In GNU ld, the actual implementation may be more complex
> > >> > with indirect symbol involved. I believe the whole thing can be simplified a
> > >> > lot by using renaming semantic. I debugged this area last year and may
> > >> > misremember something.
> > >>
> > >> It is OK to extend .symver directive.  Change it to rename semantic isn't an
> > >> option.
> > >>
> > >
> > >Updated patch to call symbol_remove to remove the symbol
> > >if it isn't used in relocation.
> > >
> > >--
> > >H.J.
> >
> > Is the second .symver required to be after the definition?
> >
> > Case A
> >
> > .symver foo,foo@@v2
> > .symver foo,foo@v1
> >
> > .globl foo
> > foo:
> >    ret
> >
> > % as-new a.s
> > a.s: Assembler messages:
> > a.s: Error: local label `"0" (instance number 0 of a dollar label)' is not defined
> >
> > Case B
> >
> > .globl foo
> > foo:
> >    ret
> >
> > .symver foo,foo@@v2
> > .symver foo,foo@v1
> > .hidden foo
> >
> >       5: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN     1 foo
> >       6: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN     1 foo@@v2
> >       7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    1 foo@v1
>
> Here is the updated patch with the above issues fixed.
>
> Thanks.
>

PING:

https://sourceware.org/pipermail/binutils/2020-April/110622.html

-- 
H.J.

  reply	other threads:[~2020-04-20 14:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07 12:10 H.J. Lu
2020-04-07 12:41 ` Andreas Schwab
2020-04-07 12:49   ` H.J. Lu
2020-04-07 12:55     ` Andreas Schwab
2020-04-07 12:57       ` V2 " H.J. Lu
2020-04-07 21:22         ` Fangrui Song
2020-04-07 23:15           ` H.J. Lu
2020-04-07 23:58             ` Fangrui Song
2020-04-08 12:53               ` H.J. Lu
2020-04-08 13:21                 ` V3 " H.J. Lu
2020-04-09 17:16                   ` Fangrui Song
2020-04-11 14:22                     ` V4 " H.J. Lu
2020-04-20 14:03                       ` H.J. Lu [this message]
2020-04-21 10:21                         ` PING: " Nick Clifton
2020-04-21 23:20                           ` Alan Modra
2020-04-21 23:52                             ` Alan Modra
2020-04-22  1:19                               ` H.J. Lu
2020-04-22  2:21                                 ` Alan Modra
2020-04-22  8:51                                   ` Alan Modra
2020-04-22 12:14                                     ` 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='CAMe9rOo84x2aBf89VUg52T-uQ3xDyL_iWuap-x4b=19EnPHBhA@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=i@maskray.me \
    --cc=nickc@redhat.com \
    --cc=schwab@linux-m68k.org \
    /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).