Re: Weak x86 aliases

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 29/12/2018 à 08:40, Cherry G.Mathew a écrit :
> Maxime Villard <max%m00nbsd.net@localhost> writes:
> > Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
> > > Maxime Villard <max%m00nbsd.net@localhost> writes:
> > > > Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
> > > > > Maxime Villard <max%m00nbsd.net@localhost> writes:
> > > > > > > Introduce a weak alias method of exporting different implementations
> > > > > > > of the same API.
> > > > > >
> > > > > > Please revert or fix this change.
> > > > >
> > > > > I'm not sure what the fix is - do you have a suggestion ?
> > > >
> > > > either re-apply it without using weak symbols, or change the modloader
> > > > to accept weak symbols
> > >
> > > I don't like the imperative in your tone. NVMM is the user of modloader,
> > > not PVHVM. So if you feel like your usecase needs fixing, I'd say it's
> > > your problem - or don't use modules, but see below.
> >
> > Wut? Yes my suggestions are either we re-apply the change without using
> > weak symbols or we change the modloader to accept weak symbols.
>
> Would a __strong_alias() fix this for you ? ie; is aliasing problematic
> in itself ?

Replacing WEAK_ALIAS by STRONG_ALIAS in amd64/amd64/cpufunc.S does fix the
problem for me.