Symver attribute

[Jan Hubicka]

> * Jan Hubicka:
> 
> > Internally the patch tries to mimic what happens in ELF.  In particular
> >
> > __attribute__ ((__symver__ ("foo@VERS_1"))) int
> > foo_v1 (void)
> > {
> > }
> >
> > creates a special form of alias with symver flag. Its assembler name is
> > foo@VERS_1 since it is what happens in ELF too (normally @ is not
> > allowed in symbol name).  Rest of GCC and LTO path handles is as normal
> > alias (since it seems what binutils does as well) and instead of
> > outputting it via .set we use .symver directive at the end.
> 
> Do you support foo@@VERS_1 for setting the default version as well?

Yes, i only reject the string if number of @'s is less then 1 or more
than 2 :)
(I wonder if there is better checking on that string)
> 
> It's sometimes useful to define multiple versions for a single symbol.
> For maximum binutils compatibility, you would have to use intermediate
> aliases.  __attribute__ ((__symver__ ("foo@VERS_1", "foo@@VERS_2")))
> could turn into this:
> 
>   .set foo_v1.symver.1, foo_v1
>   .symver foo_v1.symver.1, foo_v1@VERS_1
>   .set foo_v1.symver.2, foo_v1
>   .symver foo_v1.symver.2, foo_v1@@VERS_2

I was originaly supporting multiple symvers like:
__attribute__ ((__symver__ ("foo@VERS_1"))) int
__attribute__ ((__symver__ ("foo@VERS_2"))) int
foo_v1 (void)
{
}

but then noticed it is rejected by gas.

I intended to support:

__attribute__ ((__symver__ ("foo@VERS_1"))) int
foo_v1 (void)
{
}

int symver_foo_v1 (void)
__attribute__ ((__symver__ ("foo@VERS_2")))
__attribute__ ((alias ("foo_v1")))

This describes what you want to do: create an alias symbol and then
attach version to it.  This is broken in current patch (though i
indended it to work).  I will fix that:
        .symver foo_v1, foo@VERS_2
        .globl  symver_foo_v1
        .set    symver_foo_v1,foo_v1
        .symver foo_v1, foo@VERS_1
GCC currently redirect aliases to the their ultimate targets. I need to
implement an exception here. (We already do that for weakrefs and
syntactic aliases)

It would be prettier to support former but we need an exported symbol
name for the second alis, right?

Honza
> 
> Sometimes it's also necessary to reference a symbol version.  I
> suspect we'd need a separate attribute for that, or enhance the
> __asm__ alias code to recognize @ and @@ symbols (also creating
> internal aliases).
> 
> We would use both extensions (multiple symbol versions and symbol
> references) internally for glibc eventually, once compiler versions
> before GCC 10 are no longer supported.