On Wed, Aug 26, 2020 at 4:34 AM Martin Liška <mli...@suse.cz> wrote:
>
> On 8/26/20 1:27 PM, Jan Hubicka wrote:
> >> 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).
>
> Now I see how is this more complicated :) Can you please send the patch
> you have for this?
>
> >
> > 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.
>
> Maybe H.J. can chime in what was motivation for implementation of the syntax?
What is the question?
--
H.J.
