This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Should x86-64 support arbitrary calling conventions?
* H. J. Lu:
> On Fri, Mar 24, 2017 at 10:07 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * Zack Weinberg:
>>
>>> On Fri, Mar 24, 2017 at 12:43 PM, Florian Weimer <fw@deneb.enyo.de>
>>> wrote:
>>>>>> I think the main benefit is that we don't have to adjust the dynamic
>>>>>> linker trampoline for each new microarchitecture, and applications can
>>>>>> safely start using new CPU features once the kernel indicates support.
>>>>>
>>>>> That is true.
>>>>
>>>> I think this alone is sufficient value to make this change.
>>>>
>>>> What do others think?
>>>
>>> I still want to know why the dynamic linker trampoline has to do this
>>> in the first place. Why can't we "simply" avoid touching the
>>> floating-point and vector registers at all? Like how the kernel
>>> mostly restricts itself to integer instructions.
>>
>> It requires a special C compilation mode for the dynamic linker and
>> its dependencies, a new set of string functions, and some mechanism to
>> prevent interposition of the real string function implementations into
>> ld.so.
>
> There are also "foreign calls" in ld.so, where functions in libc.so are
> used and vector registers may be cloberred.
Right. But the _dl_fixup path relevant to the trampoline should not
do that much work. (Not sure if audit modules come into play here.)
The largest problem probably is this: IFUNC resolvers would have to be
compiled in that special way, too, and those can reside in
applications. If we fix the scheduling of those calls, there will be
a reasonable expectation that they can safely call string functions
such as memcpy and memcmp.