On Fri, Mar 14, 2014 at 4:05 AM, Andrew Pinski <pins...@gmail.com> wrote: > 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. >
To be precise, you probably want this one ( http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01968.html ) which gives the reason rather than the other bits about xor. on PowerPC. It looks like the fundamental reason is to keep this in registers for as little time as possible and not allow this to get spilled to the stack where it may be picked up for an exploit. That may make more sense from a security point of view. regards Ramana > 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
