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: Florian Weimer <fw at deneb dot enyo dot de>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Zack Weinberg <zackw at panix 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: Fri, 24 Mar 2017 18:34:57 +0100
- 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> <CAMe9rOpve0gyP6a-3zjzTJFpzxG-qVW0ycrCLzEYyC56U3LfbA@mail.gmail.com> <871stmaalw.fsf@mid.deneb.enyo.de> <CAKCAbMg2a6u_14VijWH+Jycnr4NHZkNMq0Y9EGT39ko0qjmsaQ@mail.gmail.com> <87r31m8uyk.fsf@mid.deneb.enyo.de> <CAMe9rOpOOZbJMTSv-O0m66RNzOgGrFyyUWOG=NBU_ReFJJUqXA@mail.gmail.com> <87mvca8u90.fsf@mid.deneb.enyo.de> <alpine.LNX.2.20.13.1703242028380.30883@monopod.intra.ispras.ru>
* Alexander Monakov:
> On Fri, 24 Mar 2017, Florian Weimer wrote:
>> > There are also "foreign calls" in ld.so, where functions in libc.so are
>> > used and vector registers may be cloberred.
>>
>> Right. But the _dl_fixup path relevant to the trampoline should not
>> do that much work. (Not sure if audit modules come into play here.)
>>
>> The largest problem probably is this: IFUNC resolvers would have to be
>> compiled in that special way, too, and those can reside in
>> applications.
>
> The libc can save vector register as-needed, just before calling
> external code (such as ifunc resolvers and audit callbacks).
Right, that might be a reasonable alternative.
But as I said, the XSAVE-based approach has the advantage that future
CPUs will no longer require glibc changes. In the past, that has been
a constant source of headaches (both bugs and performance problems).