[PATCH] Make target_clones resolver fn static.

[Richard Biener]

On Tue, Jan 21, 2020 at 1:48 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 1/20/20 3:52 PM, Richard Biener wrote:
> > On Mon, Jan 20, 2020 at 3:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Mon, Jan 20, 2020 at 6:41 AM Alexander Monakov <amonakov@ispras.ru> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, 20 Jan 2020, H.J. Lu wrote:
> >>>
> >>>>> Bare IFUNC's don't seem to have this restriction. Why do we want to
> >>>>> constrain target clones this way?
> >>>>>
> >>>>
> >>>> foo's resolver acts as foo.  It should have the same visibility as foo.
> >>>
> >>> What do you mean by that? From the implementation standpoint, there's
> >>> two symbols of different type with the same value. There's no problem
> >>> allowing one of them have local binding and the other have global binding.
> >>>
> >>> Is there something special about target clones that doesn't come into
> >>> play with ifuncs?
> >>>
> >>
> >> I stand corrected.   Resolver should be static and it shouldn't be weak.
> >
> > Reading the patch again and looking up more context it seems that the resolver
> > is already static we just mangle it extra when the original function
> > is public (?)
> > If so the patch looks quite obvious to me if we use some character not valid
> > in indetifiers in C but valid in assembly for the resolver decl.
>
> Hello.
>
> I'm sending updated version of the patch where I'm adding a run-time test
> for 2 static symbols (with the same name) and it works fine. Moreover
> I'm newly setting TREE_PUBLIC (ifunc_alias_decl) = 0 which seems to
> work properly.
>
> I tested both x86_64-linux-gnu and ppc64le-linux-gnu.

So this doesn't help review including two different target changes.  Making
ifunc dispatchers of public functions non-public looks like an unrelated thing
to the bug (sorry if I mis-suggested).  So I feel comfortable approving the
earlier patch which just dropped the extra mangling for non-public dispatchers
in the x86 backend.  The other thing looks like sth for next stage1?

Thanks,
Richard.

> Martin
>
> >
> > Richard.
> >
> >>
> >> --
> >> H.J.
>