RFC: Should x86-64 support arbitrary calling conventions?

[Pip Cet]

On Mon, Mar 27, 2017 at 5:36 AM, Richard Henderson <rth@twiddle.net> wrote:
> On 03/24/2017 07:31 PM, Florian Weimer wrote:
>>
>> * H. J. Lu:
>> 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.
>
>
> Not quite true, at least as written.  The STATE_SAVE_MASK define selects
> which components get saved.  This would have to be changed for additional
> cpu bits that could be modified.
>
> One *could* set EAX:EDX = -1 and store everything, and then, yes, we'd be
> done with changes to glibc for all cpu changes.

There's at least one (irrelevant, at present) CPU feature which works
better without its state being restored around some functions: AMD's
Light-Weight Profiling (http://support.amd.com/TechDocs/43724.pdf). I
think I'm the only one who made a recent effort to get it to do
something useful, and I've pretty much failed, but it's possible some
other CPU feature will also store general book-keeping state in the
XSAVE area.

So new XSAVE bits will have to be monitored either way, though it
seems safer to set them to 1 for now and clear them as needed rather
than doing things the other way around.