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.
> -/* { 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.shawcr...@gmail.com> wrote:
> Hi Venkat,
>
> On 22 January 2014 16:57, Venkataramanan Kumar
> <venkataramanan.ku...@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
