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.
--
Joseph S. Myers
jos...@codesourcery.com
