This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] [PATCH, AARCH64] : Using standard patterns for stack protection.
- From: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- To: Venkataramanan Kumar <venkataramanan dot kumar at linaro dot org>
- Cc: Marcus Shawcroft <marcus dot shawcroft at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Patch Tracking <patch at linaro dot org>
- Date: Tue, 4 Feb 2014 16:09:56 +0000
- Subject: Re: [RFC] [PATCH, AARCH64] : Using standard patterns for stack protection.
- Authentication-results: sourceware.org; auth=none
- References: <CAJK_mQ0JNdLBL6nzTM+GPrCcMZvLPRs3aCXBO-kFmyrU77GAfw at mail dot gmail dot com>
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