Symver attribute

[Jan Hubicka]

> On Fri, 15 Nov 2019, Jan Hubicka wrote:
> 
> > 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.
> 
> That's <https://sourceware.org/bugzilla/show_bug.cgi?id=23840>.
> 
> > 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
> 
> I'd rather GCC created those aliases automatically (with names that can't 
> be used as C symbols, e.g. containing '.', if possible, or failing that 
> implementation-namespace names that are unlikely to conflict with C 
> symbols), so that the API doesn't replicate a peculiarity of the assembler 
> implementation.

OK, this is quite easy to implement incrementally.  So the idea would be
to accept
__attribute__ ((__symver__ ("foo@VERS_1"))) int
__attribute__ ((__symver__ ("foo@VERS_2"))) int
foo_v1 (void)
{
}
and make GCC to produce two public symbols (foo_v1 and
foo_v1.somemangling) and attaching first symver alias
to foo_v1 and other to foo_v1.somemangling?

Honza
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com