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?
- From: Pip Cet <pipcet at gmail dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, "H.J. Lu" <hjl dot tools at gmail dot com>, "Kreitzer, David L" <david dot l dot kreitzer at intel dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, "Maslov, Sergey V" <sergey dot v dot maslov at intel dot com>
- Date: Mon, 27 Mar 2017 06:41:59 +0000
- Subject: Re: RFC: Should x86-64 support arbitrary calling conventions?
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoLSU=zfhdS1DqKQVr-5Hr9jqBjoR_CMUyFHQ8JKJfwZw@mail.gmail.com> <20170316232737.GD24205@vapier> <CAMe9rOrx5Kzwniv+UqQ+xi2FpDBf8sFeogimwcS6YUHuT2pk+Q@mail.gmail.com> <100440FED7798443A51E0730E25E29E85AAC14B5@fmsmsx117.amr.corp.intel.com> <a6e085c3-884d-3156-9b43-35094dfbc042@redhat.com> <100440FED7798443A51E0730E25E29E85AAD9939@fmsmsx117.amr.corp.intel.com> <CAMe9rOrfoekW=gu8_sWTiTECedJCVs1xZ7byZFT15a_Kxk6LAw@mail.gmail.com> <87shm3f2bj.fsf@mid.deneb.enyo.de> <9b684477-7bb5-6a0e-f966-f4a40e845b5c@twiddle.net>
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.