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: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Zack Weinberg <zackw at panix dot com>, Florian Weimer <fw at deneb dot enyo dot de>
- Cc: <nd at arm dot com>, "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 11:40:25 +0100
- Subject: Re: RFC: Should x86-64 support arbitrary calling conventions?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- 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> <CAKCAbMj1m+d+QdOD8nGewcEe=-1RFjCz=nJS0tdD_hva5995FA@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.