Re: Weak x86 aliases

[Cherry G.Mathew <cherry%zyx.in@localhost>]

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.

>>> The kernel modules that use these functions can't be modloaded
>>> anymore, because weak symbols aren't resolved.
>>>
>>> Eg, NVMM can't be modloaded anymore, because it uses rcr0 among others.
>>>
>>
>> I think I'll revert these for now, because PVHVM doesn't/shouldn't use
>> them anyway, but I'd like to know how to fix this properly. modload not
>> working due to __weak_alias() sounds like something we don't do properly
>> in the modload path.
>
> There is a check in kobj_sym_lookup():
>
> 926 	case STB_WEAK:
> 927 		kobj_error(ko, "weak symbols not supported");
> 928 		return EINVAL;
>
> To resolve correctly I guess we need to take the strongest of the
> duplicated symbols.
>

I'll look into this unless someone else beats me to it - but for now I'm
ok for the specific change that breaks things for NVMM to be rolled
back.

(Please see other email about timeframe).


-- 
~cherry