Re: Avoid two SSP ABI's for AArch64.

["Carlos O'Donell" <carlos at redhat dot com>]

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?

Cheers,
Carlos.