> On 8/26/20 11:22 AM, Jan Hubicka wrote:
> > > On 8/25/20 8:46 PM, Jan Hubicka wrote:
> > > > What will happen here with protected visibility?
> > >
> > > I forgot about it. Should it be mapped also to "local"?
> > >
> > > + const char *visibility = NULL;
> > > + if (!TREE_PUBLIC (origin_decl))
> > > + visibility = "remove";
> > > + else if (DECL_VISIBILITY (origin_decl) == VISIBILITY_INTERNAL
> > > + || DECL_VISIBILITY (origin_decl) == VISIBILITY_PROTECTED)
> > > + visibility = "local";
> > > + else if (DECL_VISIBILITY (origin_decl) == VISIBILITY_HIDDEN)
> > > + visibility = "hidden";
> >
> > I have no idea (depends what gas will do), you need to check if the
> > resulting symbol will indeed have right visibility in all of the cases.
> > If some of them are not possible, I suppose we could just reject the
> > comination.
>
> Ok, so I experimented a bit with the .symver attribute I don't see how
> is the new syntax handy (I mean .symver foo, foo@VERS_2, hidden and
> .symver foo, foo@VERS_1, local)?
>
> For instance:
>
> $ cat vi2.c
> int
> __attribute__((visibility ("hidden")))
> hidden_object;
>
> extern int
> __attribute__ ((__symver__ ("foo@@VERS_2")))
> __attribute__ ((alias ("hidden_object")))
> symver_foo_v1;
>
> $ gcc vi2.c -S
> $ cat vi2.s | grep '\.symver'
> .symver symver_foo_v1, foo@@VERS_2
>
> $ readelf -s vi2.o -W
> ...
> 8: 0000000000000000 4 OBJECT GLOBAL HIDDEN 3 hidden_object
> 9: 0000000000000000 4 OBJECT GLOBAL DEFAULT 3 symver_foo_v1
> 10: 0000000000000000 4 OBJECT GLOBAL DEFAULT 3 foo@@VERS_2
>
> Which seems fine to me. Similarly one can directly modify visibility of
> symver_foo_v1 with:
> .hidden symver_foo_v1
>
> Or do I miss something?
At low-level (and how GCC symtab should understand it), symver is just
a symbol with funny name. Alias is just another symbol pointing to same
place and in general we want to handle versions as aliases with funny
names.
But it is not how gas interpret its.
Writting .symver foo, foo@VERS_2 in my understnading does two things
1) it makes gas to turn all apperances of references to "foo" to "foo@VERS_2"
this is necessary since gas syntax does not allow names with @ in it
so otherwise we have no way to reffer to it
2) it either exports the foo symbol (and you can add visibility).
or makes foo@VERS_2 disappear depending how you declare visibilities
of foo.
With this we lose way to refernece to actul symbol foo (and not
foo@VERS_2) which may be needed in LTO if one symbol declares foo and
other declares foo with symtab attribute.
So I think we want symver attributes of symbol "foo" to produce a local
alias "foo.localalias" which will be renamed for GAS to "foo@VERS_2".
Symtab can understand this via syntactic aliases. Then we have way to
refer to symbol "foo" if we want "foo" and "foo.localalias" if we want
"foo@VERS_2". I had patch for that but I stopped on the situation that
there was no way to prevent gas from doing 2).
So I see reason for .symbol X,Y, local
I do not see much morivation for others, that is why I stopped on
updating the patch for new gas syntax - wanted to take some time to
understand it (and the time did not materialized).
So it seems to me that taking that old patch (or patch of yours) and add
the local alias machinery will do the trick, but I may be missing
something.
Honza
