V4 [PATCH] gas: Extend .symver directive
H.J. Lu
hjl.tools@gmail.com
Sat Apr 11 14:22:59 GMT 2020
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.
--
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gas-Extend-.symver-directive.patch
Type: text/x-patch
Size: 30729 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20200411/8e44065f/attachment-0001.bin>
More information about the Binutils
mailing list