This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Should x86-64 support arbitrary calling conventions?


* 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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]