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?
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.
> I don't know how well-tested x86-64 compilation without vector or
> floating-point support is. One could argue that because the kernel
> uses this mode, it should just work.
>
>> (Come to think of it, saving and restoring these registers will
>> vitiate the context switch optimizations for programs that only need
>> the integer registers.)
>
> As far as I understand things, this is not a problem with XSAVE.
--
H.J.