> On Sat, 30 Nov 2019, Jan Hubicka wrote:
>
> > > 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?
>
> Yes, that sort of thing. For glibc we'd want to be able to add extra
> symbol versions on separate declarations of foo_v1 after it's been defined
> rather than requiring all the attributes to be on the definition.
OK, if I get it right, the gcc-generated mangled symbol will be exported
and end up in the DSO symbol table that is not very cool. Can we use
local aliases here (where such thing would be OK) with foo@@@vers_1
.symver directive? This seem to produce symbol version but does not
export anything?
Honza
