This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Avoid two SSP ABI's for AArch64.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Venkataramanan Kumar <venkataramanan dot kumar at linaro dot org>, Will Newton <will dot newton at linaro dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 06 Dec 2013 15:31:01 +0000
- Subject: Re: Avoid two SSP ABI's for AArch64.
- Authentication-results: sourceware.org; auth=none
- References: <529CC927 dot 3040800 at redhat dot com> <CABXK9nejJW9EA7Y8edbt9ugC-Y5GvzSJpSBzLKpT7tkKfGqWuw at mail dot gmail dot com> <52A1ECBA dot 4090400 at redhat dot com>
On 06/12/13 15:26, Carlos O'Donell wrote:
> On 12/06/2013 09:26 AM, Marcus Shawcroft wrote:
>> The first sequence is a very common A64 idiom, while the latter
>> sequence is much less common. From discussion with various
>> u-architects I am led to believe that given a range of different
>> AArch64 u-architectures each with a unique set of design trade offs,
>> the MRS implementation is a best going to have equivalent performance
>> to the ADRP, but will be most likely to have the largest variation in
>> implementation performance.
>>
>> My view therefore is that we should run with the __stack_chk_guard
>> global data mechanism.
>
> I appreciate you reaching out to the contacts you have and for making
> a decision on this.
>
> Can I get you to confirm that for AArch64 we're going to use the
> global data access mechanism for the stack guard value used by
> the stack smashing code code?
>
> This means no ABI change for LLVM or GCC.
>
> Cheers,
> Carlos.
>
>
Carlos,
It's my understanding that glibc currently supports one model or the
other in the code, but not both.
Is there any technical reason why it could not simultaneously support
both? If it did, what would be the cost of doing so? Simple one-off
cost or significant run-time cost?
I'm not saying that we would want to do that today, but knowing that it
was possible would make me happier about taking a relatively finely
balanced decision today.
R.