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: Mon, 09 Dec 2013 10:08:59 +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> <52A1EDB5 dot 3040807 at arm dot com> <52A34409 dot 4060902 at redhat dot com>
On 07/12/13 15:51, Carlos O'Donell wrote:
> On 12/06/2013 10:31 AM, Richard Earnshaw wrote:
>> 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.
>
> That is correct.
>
>> 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?
>
> There is no technical reason for not supporting both (there are few
> technical reasons ever, it's mostly expert opinion about design).
>
> At present the most significant cost is maintaining, testing and
> synchronizing the two ABIs.
>
> If we want to support two ABIs I will strongly oppose any patch that
> doesn't provide a patch for testing both ABIs and ensuring that
> the build continues to support both ABIs.
>
> The synchronization at present is easy, set both values to the same
> value at startup. I can't say what will happen in the future or if this
> will limit future design changes. That is another factor and another
> reason for limiting the supported ABIs.
>
>> 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.
>
> I would "like" to maintain one SSP ABI per target. That simplifies the
> maintenance, debugging and doesn't limit future design changes.
>
> If ARM argues eloquently that the optimal ABI per target actually
> depends on micro-architecture variants then that's another question.
> I'm not arguing against such a statement, but I am arguing that we need
> better testing and I'll oppose such changes without due-diligence in
> additional tests for glibc.
>
> For example it's already the case for 32-bit ARM that newer ARM targets
> might benefit from using TP+offset, but because glibc supports only one
> such SSP ABI we have chosen global symbol as the default. Enabling both
> tp+offset and global symbol might benefit newer 32-bit ARM cores.
>
> Again, I want to see engineering rigour here, clear performance arguments
> (or claims from experts) and testing improvements for this. We already
> have pointer guard and stack guard tests, but they only test one ABI.
> They need to be recompiled with a distinct set of stackguard-macros.h
> for each SSP ABI variant and re-run as unique tests.
>
> Does that make sense?
>
Thanks,
I do not expect to need to change/add the alternative ABI interface, but
knowing that it should be technically possible means I can go forward
with what I believe today to be the correct decision with much more
confidence.
So on that basis I think we should stick with the default ABI -- ie
using __stack_chk_guard.
R.