On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar <venkataramanan.ku...@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.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
