[RFC] [PATCH, AARCH64] : Using standard patterns for stack protection.

[Andrew Pinski]

On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
<venkataramanan.kumar@linaro.org> wrote:
> Hi Marcus,
>
>> +  "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>> +  [(set_attr "length" "12")])
>>
>> This pattern emits an opaque sequence of instructions that cannot be
>> scheduled, is that necessary? Can we not expand individual
>> instructions or at least split ?
>
> Almost all the ports emits a template of assembly instructions.
> I m not sure why they have to be generated this way.
> But usage of these pattern is to clear the register that holds canary
> value immediately after its usage.

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01981.html answer the
original question of why.  It was a reply to the exact same question
being asked here but about the rs6000 (PowerPC) patch.

Thanks,
Andrew Pinski

>
>> -/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
>> +/* { dg-do compile { target stack_protection } } */
>>  /* { dg-options "-O2 -fstack-protector-strong" } */
>>
>> Do we need a new effective target test, why is the existing
>> "fstack_protector" not appropriate?
>
> "stack_protector" does a run time test. It failed in cross compilation
> environment and these are compile only tests.
> Also I thought  richard suggested  me to add a new option for this.
> ref: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03358.html
>
> regards,
> Venkat.
>
> On 4 February 2014 21:39, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
>> Hi Venkat,
>>
>> On 22 January 2014 16:57, Venkataramanan Kumar
>> <venkataramanan.kumar@linaro.org> wrote:
>>> Hi Marcus,
>>>
>>> After we changed the frame growing direction (downwards) in Aarch64,
>>> the back-end now generates stack smashing set and test based on
>>> generic code available in GCC.
>>>
>>> But most of the ports (i386, spu, rs6000, s390, sh, sparc, tilepro and
>>> tilegx) define machine descriptions using standard pattern names
>>> 'stack_protect_set' and 'stack_protect_test'. This is done for both
>>> TLS model as well as global variable based stack guard model.
>>
>> +  ""
>> +  "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>> +  [(set_attr "length" "12")])
>>
>> This pattern emits an opaque sequence of instructions that cannot be
>> scheduled, is that necessary? Can we not expand individual
>> instructions or at least split ?
>>
>> +  "ldr\t%x3, %x1\;ldr\t%x0, %x2\;eor\t%x0, %x3, %x0"
>> +  [(set_attr "length" "12")])
>>
>> Likewise.
>>
>> -/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
>> +/* { dg-do compile { target stack_protection } } */
>>  /* { dg-options "-O2 -fstack-protector-strong" } */
>>
>> Do we need a new effective target test, why is the existing
>> "fstack_protector" not appropriate?
>>
>> Cheers
>> /Marcus