RFC: Should x86-64 support arbitrary calling conventions?

[Szabolcs Nagy]

On 24/03/17 17:58, Zack Weinberg wrote:
> On Fri, Mar 24, 2017 at 1:07 PM, 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.
> 
> I feel that this would wind up being worth doing, but since it is
> obviously a great deal of work and the proposed patch l doesn't
> prevent us from coming back to it later, I won't stand in the way.
> 

even if the dynamic linker was careful not to
clobber certain registers in memcpy/strcmp/..,
ifunc resolvers follow the normal pcs, so they
are allowed to clobber them anyway.

so in general 'the dynamic linker is careful'
argument does not work in the presence of
user defined ifunc.