RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi All,

I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.

OK for backport?

Thanks,
Tamar

> -Original Message-
> From: Jeff Law 
> Sent: Friday, August 3, 2018 19:03
> To: Tamar Christina ; Joseph Myers
> 
> Cc: gcc-patches@gcc.gnu.org; nd ; bonz...@gnu.org;
> d...@redhat.com; nero...@gcc.gnu.org; aol...@redhat.com;
> ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> On 07/24/2018 08:14 AM, Tamar Christina wrote:
> > Hi All,
> >
> > Here's an updated patch with documentation.
> >
> >
> > Ok for trunk?
> >
> > Thanks,
> > Tamar
> >
> > gcc/
> > 2018-07-24  Tamar Christina  
> >
> > PR target/86486
> > * configure.ac: Add stack-clash-protection-guard-size.
> > * doc/install.texi: Document it.
> > * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
> > * params.def: Update comment for guard-size.
> > * configure: Regenerate.
> >
> > The 07/24/2018 11:34, Joseph Myers wrote:
> >> On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:
> >>
> >>> This patch defines a configure option to allow the setting of the
> >>> default guard size via configure flags when building the target.
> >> If you add a configure option, you must also add documentation for it
> >> in install.texi.
> >>
> >> --
> >> Joseph S. Myers
> >> jos...@codesourcery.com
> > --
> >
> >
> > rb9473-3.patch
> >
> 
> OK.
> jeff

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Jeff Law]

On 07/24/2018 08:14 AM, Tamar Christina wrote:
> Hi All,
> 
> Here's an updated patch with documentation.
> 
> 
> Ok for trunk?
> 
> Thanks,
> Tamar
> 
> gcc/
> 2018-07-24  Tamar Christina  
> 
>   PR target/86486
>   * configure.ac: Add stack-clash-protection-guard-size.
>   * doc/install.texi: Document it.
>   * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
>   * params.def: Update comment for guard-size.
>   * configure: Regenerate.
> 
> The 07/24/2018 11:34, Joseph Myers wrote:
>> On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:
>>
>>> This patch defines a configure option to allow the setting of the default
>>> guard size via configure flags when building the target.
>> If you add a configure option, you must also add documentation for it in 
>> install.texi.
>>
>> -- 
>> Joseph S. Myers
>> jos...@codesourcery.com
> -- 
> 
> 
> rb9473-3.patch
> 

OK.
jeff

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi Alexandre,

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> On Behalf Of Alexandre Oliva
> Sent: Thursday, July 26, 2018 08:46
> To: Tamar Christina 
> Cc: Joseph Myers ; Jeff Law
> ; gcc-patches@gcc.gnu.org; nd ;
> bonz...@gnu.org; d...@redhat.com; nero...@gcc.gnu.org;
> ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> On Jul 25, 2018, Tamar Christina  wrote:
> 
> > gcc/
> > 2018-07-25  Tamar Christina  
> 
> > PR target/86486
> > * configure.ac: Add stack-clash-protection-guard-size.
> > * doc/install.texi: Document it.
> > * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
> > * params.def: Update comment for guard-size.
> > (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE,
> > PARAM_STACK_CLASH_PROTECTION_PROBE_INTERVAL): Update
> description.
> > * configure: Regenerate.
> 
> Thanks.  No objections from me.  I don't see any use of the new config knob,
> though; assuming it's in a subsequent patch, I guess this one is fine, but I'm
> not sure I'm entitled to approve it.

Yup it's in a subsequent AArch64 patch.  That's no problem, Jeff still has to 
review
the other front-end patch so I'll have to wait for approval there anyway.

Thanks for the review and comments!

Regards,
Tamar

> 
> --
> Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
> Be the change, be Free! FSF Latin America board member
> GNU Toolchain EngineerFree Software Evangelist

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Alexandre Oliva]

On Jul 25, 2018, Tamar Christina  wrote:

> gcc/
> 2018-07-25  Tamar Christina  

>   PR target/86486
>   * configure.ac: Add stack-clash-protection-guard-size.
>   * doc/install.texi: Document it.
>   * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
>   * params.def: Update comment for guard-size.
>   (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE,
>   PARAM_STACK_CLASH_PROTECTION_PROBE_INTERVAL): Update description.
>   * configure: Regenerate.

Thanks.  No objections from me.  I don't see any use of the new config
knob, though; assuming it's in a subsequent patch, I guess this one is
fine, but I'm not sure I'm entitled to approve it.

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

HI Alexandre,

Thanks for the review. Attached is the updated patch and new changelog below:

Thanks,
Tamar

gcc/
2018-07-25  Tamar Christina  

PR target/86486
* configure.ac: Add stack-clash-protection-guard-size.
* doc/install.texi: Document it.
* config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
* params.def: Update comment for guard-size.
(PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE,
PARAM_STACK_CLASH_PROTECTION_PROBE_INTERVAL): Update description.
* configure: Regenerate.

> -Original Message-
> From: Alexandre Oliva 
> Sent: Tuesday, July 24, 2018 20:24
> To: Tamar Christina 
> Cc: Joseph Myers ; Jeff Law
> ; gcc-patches@gcc.gnu.org; nd ;
> bonz...@gnu.org; d...@redhat.com; nero...@gcc.gnu.org;
> ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> Hello, Christina,
> 
> On Jul 24, 2018, Tamar Christina  wrote:
> 
> > gcc/
> > 2018-07-24  Tamar Christina  
> 
> > PR target/86486
> > * configure.ac: Add stack-clash-protection-guard-size.
> > * doc/install.texi: Document it.
> > * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
> > * params.def: Update comment for guard-size.
> > * configure: Regenerate.
> 
> The configury bits look almost good to me.
> 
> I wish the help message, comments and docs expressed somehow that the
> given power of two expresses a size in bytes, rather than in kilobytes, bits 
> or
> any other unit that might be reasonably assumed to express stack sizes.  I'm
> afraid I don't know the best way to accomplish that in a few words.
> 
> > +stk_clash_default=12
> 
> This seems to be left-over from an earlier patch, as it is now unused AFAICT.
> 
> Thanks,
> 
> --
> Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
> Be the change, be Free! FSF Latin America board member
> GNU Toolchain EngineerFree Software Evangelist
diff --git a/gcc/config.in b/gcc/config.in
index 2856e72d627df537a301a6c7ab6b5bbb75f6b43f..32118ef1f94cece06a1d870416c3a1705716d21b 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -55,6 +55,13 @@
 #endif
 
 
+/* Define to larger than zero set to the default stack clash protector size as
+   a power of two in bytes. */
+#ifndef USED_FOR_TARGET
+#undef DEFAULT_STK_CLASH_GUARD_SIZE
+#endif
+
+
 /* Define if you want to use __cxa_atexit, rather than atexit, to register C++
destructors for local statics and global objects. This is essential for
fully standards-compliant handling of destructors, but requires
diff --git a/gcc/configure b/gcc/configure
index 60d373982fd38fe51c285e2b02941754d1b833d6..77ed62d199b272dfe39de156771dfb774184dd7d 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -905,6 +905,7 @@ enable_valgrind_annotations
 with_stabs
 enable_multilib
 enable_multiarch
+with_stack_clash_protection_guard_size
 enable___cxa_atexit
 enable_decimal_float
 enable_fixed_point
@@ -1724,6 +1725,9 @@ Optional Packages:
   --with-gnu-as   arrange to work with GNU as
   --with-as   arrange to use the specified as (full pathname)
   --with-stabsarrange to use stabs instead of host debug format
+  --with-stack-clash-protection-guard-size=size
+  Set the default stack clash protection guard size
+  for specific targets as a power of two in bytes.
   --with-dwarf2   force the default debug format to be DWARF 2
   --with-specs=SPECS  add SPECS to driver command-line processing
   --with-pkgversion=PKG   Use PKG in the version string in place of "GCC"
@@ -7436,6 +7440,34 @@ $as_echo "$enable_multiarch$ma_msg_suffix" >&6; }
 
 
 
+# default stack clash protection guard size as power of twos in bytes.
+# Please keep these in sync with params.def.
+stk_clash_min=12
+stk_clash_max=30
+
+# Keep the default value when the option is not used to 0, this allows us to
+# distinguish between the cases where the user specifially set a value via
+# configure and when the normal default value is used.
+
+# Check whether --with-stack-clash-protection-guard-size was given.
+if test "${with_stack_clash_protection_guard_size+set}" = set; then :
+  withval=$with_stack_clash_protection_guard_size; DEFAULT_STK_CLASH_GUARD_SIZE="$with_stack_clash_protection_guard_size"
+else
+  DEFAULT_STK_CLASH_GUARD_SIZE=0
+fi
+
+if test $DEFAULT_STK_CLASH_GUARD_SIZE -ne 0 \
+ && (test $DEFAULT_STK_CLASH_GUARD_SIZE -lt $stk_clash_min \
+	 || test $DEFAULT_STK_CLASH_GUARD_SIZE -gt $stk_clash_max); then
+  as_fn_error "Invalid value $DEFAULT_STK_CLASH_GUARD_SIZE for --with-stack-clash-protection-guard-size. Must be between $stk_clash_min and $stk_clash_max.&qu

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Alexandre Oliva]

Hello, Christina,

On Jul 24, 2018, Tamar Christina  wrote:

> gcc/
> 2018-07-24  Tamar Christina  

>   PR target/86486
>   * configure.ac: Add stack-clash-protection-guard-size.
>   * doc/install.texi: Document it.
>   * config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
>   * params.def: Update comment for guard-size.
>   * configure: Regenerate.

The configury bits look almost good to me.

I wish the help message, comments and docs expressed somehow that the
given power of two expresses a size in bytes, rather than in kilobytes,
bits or any other unit that might be reasonably assumed to express stack
sizes.  I'm afraid I don't know the best way to accomplish that in a few
words.

> +stk_clash_default=12

This seems to be left-over from an earlier patch, as it is now unused
AFAICT.

Thanks,

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi All,

Here's an updated patch with documentation.


Ok for trunk?

Thanks,
Tamar

gcc/
2018-07-24  Tamar Christina  

PR target/86486
* configure.ac: Add stack-clash-protection-guard-size.
* doc/install.texi: Document it.
* config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
* params.def: Update comment for guard-size.
* configure: Regenerate.

The 07/24/2018 11:34, Joseph Myers wrote:
> On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:
> 
> > This patch defines a configure option to allow the setting of the default
> > guard size via configure flags when building the target.
> 
> If you add a configure option, you must also add documentation for it in 
> install.texi.
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

-- 
diff --git a/gcc/config.in b/gcc/config.in
index 2856e72d627df537a301a6c7ab6b5bbb75f6b43f..e853adc9aed366fe7bbc0f598e9f7137d68d7c02 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -55,6 +55,12 @@
 #endif
 
 
+/* Define to larger than zero set to the default stack clash protector size. */
+#ifndef USED_FOR_TARGET
+#undef DEFAULT_STK_CLASH_GUARD_SIZE
+#endif
+
+
 /* Define if you want to use __cxa_atexit, rather than atexit, to register C++
destructors for local statics and global objects. This is essential for
fully standards-compliant handling of destructors, but requires
diff --git a/gcc/configure b/gcc/configure
index 60d373982fd38fe51c285e2b02941754d1b833d6..513a8eada59af8314732d744b673e807829bad77 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -905,6 +905,7 @@ enable_valgrind_annotations
 with_stabs
 enable_multilib
 enable_multiarch
+with_stack_clash_protection_guard_size
 enable___cxa_atexit
 enable_decimal_float
 enable_fixed_point
@@ -1724,6 +1725,9 @@ Optional Packages:
   --with-gnu-as   arrange to work with GNU as
   --with-as   arrange to use the specified as (full pathname)
   --with-stabsarrange to use stabs instead of host debug format
+  --with-stack-clash-protection-guard-size=size
+  Set the default stack clash protection guard size
+  for specific targets as a power of two.
   --with-dwarf2   force the default debug format to be DWARF 2
   --with-specs=SPECS  add SPECS to driver command-line processing
   --with-pkgversion=PKG   Use PKG in the version string in place of "GCC"
@@ -7436,6 +7440,35 @@ $as_echo "$enable_multiarch$ma_msg_suffix" >&6; }
 
 
 
+# default stack clash protection guard size
+# Please keep these in sync with params.def.
+stk_clash_min=12
+stk_clash_max=30
+stk_clash_default=12
+
+# Keep the default value when the option is not used to 0, this allows us to
+# distinguish between the cases where the user specifially set a value via
+# configure and when the normal default value is used.
+
+# Check whether --with-stack-clash-protection-guard-size was given.
+if test "${with_stack_clash_protection_guard_size+set}" = set; then :
+  withval=$with_stack_clash_protection_guard_size; DEFAULT_STK_CLASH_GUARD_SIZE="$with_stack_clash_protection_guard_size"
+else
+  DEFAULT_STK_CLASH_GUARD_SIZE=0
+fi
+
+if test $DEFAULT_STK_CLASH_GUARD_SIZE -ne 0 \
+ && (test $DEFAULT_STK_CLASH_GUARD_SIZE -lt $stk_clash_min \
+	 || test $DEFAULT_STK_CLASH_GUARD_SIZE -gt $stk_clash_max); then
+  as_fn_error "Invalid value $DEFAULT_STK_CLASH_GUARD_SIZE for --with-stack-clash-protection-guard-size. Must be between $stk_clash_min and $stk_clash_max." "$LINENO" 5
+fi
+
+
+cat >>confdefs.h <<_ACEOF
+#define DEFAULT_STK_CLASH_GUARD_SIZE $DEFAULT_STK_CLASH_GUARD_SIZE
+_ACEOF
+
+
 # Enable __cxa_atexit for C++.
 # Check whether --enable-__cxa_atexit was given.
 if test "${enable___cxa_atexit+set}" = set; then :
@@ -18448,7 +18481,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18451 "configure"
+#line 18484 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -18554,7 +18587,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18557 "configure"
+#line 18590 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 010ecd2ccf609ded1f4d2849a2acc13aba43b55b..e839445c1aea7dc9c5a5ee8dab8191eae5298bc2 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -811,6 +811,30 @@ AC_MSG_RESULT($enable_multiarch$ma_msg_suffix)
 AC_SUBST(with_cpu)
 AC_SUBST(with_float)
 
+# default stack clash protection guard size
+# Please keep these in sync with params.def.
+stk_clash_min=12
+stk_clash_max=30
+stk_clash_default=12
+
+# Keep the default value when the option is not used to 0, this allows us to
+# distinguish between the cases where the user specifially set a value via
+# configure and when the normal default value is used.
+AC_ARG_WITH(stack-clash-protection-guard-size,

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Joseph Myers]

On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:

> This patch defines a configure option to allow the setting of the default
> guard size via configure flags when building the target.

If you add a configure option, you must also add documentation for it in 
install.texi.

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[tamar . christina]

Hi Jeff,

This patch defines a configure option to allow the setting of the default
guard size via configure flags when building the target.

The new flag is:

 * --with-stack-clash-protection-guard-size=

The patch defines a new macro DEFAULT_STK_CLASH_GUARD_SIZE which targets need
to use explicitly is they want to support this configure flag and values that
users may have set.

Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no 
issues.
Both targets were tested with stack clash on and off by default.

Ok for trunk?

Thanks,
Tamar

gcc/
2018-07-24  Tamar Christina  

PR target/86486
* configure.ac: Add stack-clash-protection-guard-size.
* config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
* params.def: Update comment for guard-size.
* configure: Regenerate.

> -Original Message-
> From: Jeff Law 
> Sent: Monday, July 23, 2018 23:19
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ;
> jos...@codesourcery.com; bonz...@gnu.org; d...@redhat.com;
> nero...@gcc.gnu.org; aol...@redhat.com; ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> On 07/20/2018 09:39 AM, Tamar Christina wrote:
> >>
> >> On 07/20/2018 05:03 AM, Tamar Christina wrote:
> >>>> Understood.  Thanks for verifying.  I wonder if we could just bury
> >>>> this entirely in the aarch64 config files and not expose the
> >>>> default into
> >> params.def?
> >>>>
> >>>
> >>> Burying it in config.gcc isn't ideal because if your C runtime is
> >>> configurable (like uClibc) it means you have to go and modify this
> >>> file every time you change something. If the argument is against
> >>> having these defines in the params and not the configure flag itself
> >>> then I
> >> can just have an aarch64 specific configure flag and just use the
> >> created define directly in the AArch64 back-end.
> >> Not config.gcc, but in a .h/.c file for the target.
> >>
> >> If we leave the generic option, but override the default in the target 
> >> files.
> >> Would that work?
> >
> > So leaving the generic configure option? Yes that would work too. The
> > only downside is that if we have want to do any validation on the
> > value at configure time it would need to be manually kept in sync with
> > those in params.def. Or we'd just have to not do any checking at
> > configure time.  This would mean you can get to the end of your build and
> only when you try to use the compiler would it complain.
> >
> > Both aren't a real deal breaker to me.
> >
> > Shall I then just leave the configure flag but remove the params plumbing?
> Yea, I think any sanity check essentially has to move to when the compiler
> runs.  We can always return to param removal at a later point.
> 
> Can you post an updated patch?  Note I'm on PTO starting Wed for a week.
>  If you post it tomorrow I'll try to take a look before I disappear.
> 
> jeff
diff --git a/gcc/config.in b/gcc/config.in
index 2856e72d627df537a301a6c7ab6b5bbb75f6b43f..f3b301ef5afdaf0db8865e11601980f19ea0b3dd 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -55,6 +55,12 @@
 #endif
 
 
+/* Define to larger than zero set the default stack clash protector size. */
+#ifndef USED_FOR_TARGET
+#undef DEFAULT_STK_CLASH_GUARD_SIZE
+#endif
+
+
 /* Define if you want to use __cxa_atexit, rather than atexit, to register C++
destructors for local statics and global objects. This is essential for
fully standards-compliant handling of destructors, but requires
diff --git a/gcc/configure b/gcc/configure
index 60d373982fd38fe51c285e2b02941754d1b833d6..42ec5b536bee90adb319d172eb7cca1a363a87b6 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -905,6 +905,7 @@ enable_valgrind_annotations
 with_stabs
 enable_multilib
 enable_multiarch
+with_stack_clash_protection_guard_size
 enable___cxa_atexit
 enable_decimal_float
 enable_fixed_point
@@ -1724,6 +1725,9 @@ Optional Packages:
   --with-gnu-as   arrange to work with GNU as
   --with-as   arrange to use the specified as (full pathname)
   --with-stabsarrange to use stabs instead of host debug format
+  --with-stack-clash-protection-guard-size=size
+  Set the default stack clash protection guard size
+  for specific targets.
   --with-dwarf2   force the default debug format to be DWARF 2
   --with-specs=SPECS  add SPECS to driver command-line processing
   --with-pkgversion=PKG   Use PKG in the version string in place of "GCC"
@@ -7436,6 +7440,35 @@ $as_echo &q

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Jeff Law]

On 07/20/2018 09:39 AM, Tamar Christina wrote:
>>
>> On 07/20/2018 05:03 AM, Tamar Christina wrote:
 Understood.  Thanks for verifying.  I wonder if we could just bury
 this entirely in the aarch64 config files and not expose the default into
>> params.def?

>>>
>>> Burying it in config.gcc isn't ideal because if your C runtime is
>>> configurable (like uClibc) it means you have to go and modify this
>>> file every time you change something. If the argument is against
>>> having these defines in the params and not the configure flag itself then I
>> can just have an aarch64 specific configure flag and just use the created
>> define directly in the AArch64 back-end.
>> Not config.gcc, but in a .h/.c file for the target.
>>
>> If we leave the generic option, but override the default in the target files.
>> Would that work?
> 
> So leaving the generic configure option? Yes that would work too. The only 
> downside is
> that if we have want to do any validation on the value at configure time it 
> would need to
> be manually kept in sync with those in params.def. Or we'd just have to not 
> do any checking
> at configure time.  This would mean you can get to the end of your build and 
> only when you
> try to use the compiler would it complain. 
> 
> Both aren't a real deal breaker to me.
> 
> Shall I then just leave the configure flag but remove the params plumbing?
Yea, I think any sanity check essentially has to move to when the
compiler runs.  We can always return to param removal at a later point.

Can you post an updated patch?  Note I'm on PTO starting Wed for a week.
 If you post it tomorrow I'll try to take a look before I disappear.

jeff

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

> 
> On 07/20/2018 05:03 AM, Tamar Christina wrote:
> >> Understood.  Thanks for verifying.  I wonder if we could just bury
> >> this entirely in the aarch64 config files and not expose the default into
> params.def?
> >>
> >
> > Burying it in config.gcc isn't ideal because if your C runtime is
> > configurable (like uClibc) it means you have to go and modify this
> > file every time you change something. If the argument is against
> > having these defines in the params and not the configure flag itself then I
> can just have an aarch64 specific configure flag and just use the created
> define directly in the AArch64 back-end.
> Not config.gcc, but in a .h/.c file for the target.
> 
> If we leave the generic option, but override the default in the target files.
> Would that work?

So leaving the generic configure option? Yes that would work too. The only 
downside is
that if we have want to do any validation on the value at configure time it 
would need to
be manually kept in sync with those in params.def. Or we'd just have to not do 
any checking
at configure time.  This would mean you can get to the end of your build and 
only when you
try to use the compiler would it complain. 

Both aren't a real deal breaker to me.

Shall I then just leave the configure flag but remove the params plumbing?

Thanks,
Tamar

> 
> Jeff

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Jeff Law]

On 07/20/2018 05:03 AM, Tamar Christina wrote:
>> Understood.  Thanks for verifying.  I wonder if we could just bury this 
>> entirely
>> in the aarch64 config files and not expose the default into params.def?
>>
> 
> Burying it in config.gcc isn't ideal because if your C runtime is 
> configurable (like uClibc) it means you
> have to go and modify this file every time you change something. If the 
> argument is 
> against having these defines in the params and not the configure flag itself 
> then I can just
> have an aarch64 specific configure flag and just use the created define 
> directly in the AArch64 back-end.
Not config.gcc, but in a .h/.c file for the target.

If we leave the generic option, but override the default in the target
files.  Would that work?

Jeff

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi Jeff,

> -Original Message-
> From: Jeff Law 
> Sent: Thursday, July 19, 2018 18:32
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ;
> jos...@codesourcery.com; bonz...@gnu.org; d...@redhat.com;
> nero...@gcc.gnu.org; aol...@redhat.com; ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> On 07/19/2018 06:55 AM, Tamar Christina wrote:
> >>>
> >>> What's the purpose of including auto-host in params-list and
> >>> params-options?  It seems like you're putting a property of the
> >>> target (guard size) into the wrong place (auto-host.h).
> >>>
> >>
> >> The reason for this is because there's a test
> >> gcc.dg/params/blocksort-part.c that uses these params-options to
> >> generate test cases to perform parameter validation. However because
> >> now the params.def file can contain a CPP macro these would then fail.
> >>
> >> CPP is already called to create params-options and params-list so the
> >> easiest way to fix this test was just to include auto-host which
> >> would get it the values from configure.
> >>
> >> This test is probably not needed anymore after my second patch series
> >> as parameters are validated by the front-end now, so they can never
> >> go out of range.
> Right, but I don't immediately see a way to avoid the test.  ie, it just walks
> down everything in params.options and except for a couple exceptional
> values the test gets run.
> 
> I wonder if all this is an indication that having CPP constants in the options
> isn't going to work well as we're mixing the distinction between host/target.
> 
> 
> >>
> >>> It's also a bit unclear to me why this is necessary at all.  Are we
> >>> planning to support both the 4k and 64k guards?  My goal (once the
> >>> guard was configurable) was never for supporting multiple sizes on a
> >>> target but instead to allow experimentation to find the right default.
> >>>
> >
> > Having talked to people I believe we do need to support both 4k and 64k
> guards.
> > For the Linux/Glibc world it wouldn't matter much, either 4 or 64k would do,
> though Glibc has settled on 64k pages.
> >
> > However other systems like (open/free)BSD or musl based systems do not
> > want 64k pages but want 4k ones.  So we're ending up having to support
> both as a compromise.
> Understood.  Thanks for verifying.  I wonder if we could just bury this 
> entirely
> in the aarch64 config files and not expose the default into params.def?
> 

Burying it in config.gcc isn't ideal because if your C runtime is configurable 
(like uClibc) it means you
have to go and modify this file every time you change something. If the 
argument is 
against having these defines in the params and not the configure flag itself 
then I can just
have an aarch64 specific configure flag and just use the created define 
directly in the AArch64 back-end.

Would that be an acceptable solution?

Thanks,
Tamar

> jeff

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Jeff Law]

On 07/19/2018 06:55 AM, Tamar Christina wrote:
>>>
>>> What's the purpose of including auto-host in params-list and
>>> params-options?  It seems like you're putting a property of the target
>>> (guard size) into the wrong place (auto-host.h).
>>>
>>
>> The reason for this is because there's a test gcc.dg/params/blocksort-part.c
>> that uses these params-options to generate test cases to perform parameter
>> validation. However because now the params.def file can contain a CPP
>> macro these would then fail.
>>
>> CPP is already called to create params-options and params-list so the easiest
>> way to fix this test was just to include auto-host which would get it the 
>> values
>> from configure.
>>
>> This test is probably not needed anymore after my second patch series as
>> parameters are validated by the front-end now, so they can never go out of
>> range.
Right, but I don't immediately see a way to avoid the test.  ie, it just
walks down everything in params.options and except for a couple
exceptional values the test gets run.

I wonder if all this is an indication that having CPP constants in the
options isn't going to work well as we're mixing the distinction between
host/target.


>>
>>> It's also a bit unclear to me why this is necessary at all.  Are we
>>> planning to support both the 4k and 64k guards?  My goal (once the
>>> guard was configurable) was never for supporting multiple sizes on a
>>> target but instead to allow experimentation to find the right default.
>>>
> 
> Having talked to people I believe we do need to support both 4k and 64k 
> guards.
> For the Linux/Glibc world it wouldn't matter much, either 4 or 64k would do, 
> though Glibc has settled on 64k pages.
> 
> However other systems like (open/free)BSD or musl based systems do not want
> 64k pages but want 4k ones.  So we're ending up having to support both as a 
> compromise.
Understood.  Thanks for verifying.  I wonder if we could just bury this
entirely in the aarch64 config files and not expose the default into
params.def?

jeff

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi Jeff,

> -Original Message-
> From: Tamar Christina 
> Sent: Thursday, July 12, 2018 18:45
> To: Jeff Law 
> Cc: gcc-patches@gcc.gnu.org; nd ;
> jos...@codesourcery.com; bonz...@gnu.org; d...@redhat.com;
> nero...@gcc.gnu.org; aol...@redhat.com; ralf.wildenh...@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> Hi Jeff,
> 
> The 07/11/2018 20:21, Jeff Law wrote:
> > On 07/11/2018 05:22 AM, Tamar Christina wrote:
> > > Hi All,
> > >
> > > This patch defines a configure option to allow the setting of the
> > > default guard size via configure flags when building the target.
> > >
> > > The new flag is:
> > >
> > >  * --with-stack-clash-protection-guard-size=
> > >
> > > The value of configured based params are set very early on and allow
> > > the target to validate or reject the values as it sees fit.
> > >
> > > To do this the values for the parameter get set by configure through CPP
> defines.
> > > In case the back-end wants to know if a value was set or not the
> > > original default value is also passed down as a define.
> > >
> > > This allows a target to check if a param was changed by the user at
> configure time.
> > >
> > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-
> gnu and no issues.
> > > Both targets were tested with stack clash on and off by default.
> > >
> > > Ok for trunk?
> > >
> > > Thanks,
> > > Tamar
> > >
> > > gcc/
> > > 2018-07-11  Tamar Christina  
> > >
> > >   PR target/86486
> > >   * configure.ac: Add stack-clash-protection-guard-size.
> > >   * config.in (DEFAULT_STK_CLASH_GUARD_SIZE,
> STK_CLASH_GUARD_SIZE_DEFAULT,
> > >   STK_CLASH_GUARD_SIZE_MAX, STK_CLASH_GUARD_SIZE_MIN):
> New.
> > >   * params.def (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE):
> Use it.
> > >   * configure: Regenerate.
> > >   * Makefile.in (params.list, params.options): Add include dir for CPP.
> > >   * params-list.h: Include auto-host.h
> > >   * params-options.h: Likewise.
> > >
> > Something seems wrong here.
> >
> > What's the purpose of including auto-host in params-list and
> > params-options?  It seems like you're putting a property of the target
> > (guard size) into the wrong place (auto-host.h).
> >
> 
> The reason for this is because there's a test gcc.dg/params/blocksort-part.c
> that uses these params-options to generate test cases to perform parameter
> validation. However because now the params.def file can contain a CPP
> macro these would then fail.
> 
> CPP is already called to create params-options and params-list so the easiest
> way to fix this test was just to include auto-host which would get it the 
> values
> from configure.
> 
> This test is probably not needed anymore after my second patch series as
> parameters are validated by the front-end now, so they can never go out of
> range.
> 
> > It's also a bit unclear to me why this is necessary at all.  Are we
> > planning to support both the 4k and 64k guards?  My goal (once the
> > guard was configurable) was never for supporting multiple sizes on a
> > target but instead to allow experimentation to find the right default.
> >

Having talked to people I believe we do need to support both 4k and 64k guards.
For the Linux/Glibc world it wouldn't matter much, either 4 or 64k would do, 
though Glibc has settled on 64k pages.

However other systems like (open/free)BSD or musl based systems do not want
64k pages but want 4k ones.  So we're ending up having to support both as a 
compromise.

Regards,
Tamar

> 
> I will get back to you on this one.
> 
> Thanks,
> Tamar
> 
> > Jeff
> 
> --

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

Hi Jeff,

The 07/11/2018 20:21, Jeff Law wrote:
> On 07/11/2018 05:22 AM, Tamar Christina wrote:
> > Hi All,
> > 
> > This patch defines a configure option to allow the setting of the default
> > guard size via configure flags when building the target.
> > 
> > The new flag is:
> > 
> >  * --with-stack-clash-protection-guard-size=
> > 
> > The value of configured based params are set very early on and allow the
> > target to validate or reject the values as it sees fit.
> > 
> > To do this the values for the parameter get set by configure through CPP 
> > defines.
> > In case the back-end wants to know if a value was set or not the original 
> > default
> > value is also passed down as a define.
> > 
> > This allows a target to check if a param was changed by the user at 
> > configure time.
> > 
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and 
> > no issues.
> > Both targets were tested with stack clash on and off by default.
> > 
> > Ok for trunk?
> > 
> > Thanks,
> > Tamar
> > 
> > gcc/
> > 2018-07-11  Tamar Christina  
> > 
> > PR target/86486
> > * configure.ac: Add stack-clash-protection-guard-size.
> > * config.in (DEFAULT_STK_CLASH_GUARD_SIZE, STK_CLASH_GUARD_SIZE_DEFAULT,
> > STK_CLASH_GUARD_SIZE_MAX, STK_CLASH_GUARD_SIZE_MIN): New.
> > * params.def (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE): Use it.
> > * configure: Regenerate.
> > * Makefile.in (params.list, params.options): Add include dir for CPP.
> > * params-list.h: Include auto-host.h
> > * params-options.h: Likewise.
> > 
> Something seems wrong here.
> 
> What's the purpose of including auto-host in params-list and
> params-options?  It seems like you're putting a property of the target
> (guard size) into the wrong place (auto-host.h).
> 

The reason for this is because there's a test gcc.dg/params/blocksort-part.c
that uses these params-options to generate test cases to perform parameter
validation. However because now the params.def file can contain a CPP
macro these would then fail.

CPP is already called to create params-options and params-list so the easiest
way to fix this test was just to include auto-host which would get it the values
from configure.

This test is probably not needed anymore after my second patch series as 
parameters
are validated by the front-end now, so they can never go out of range.

> It's also a bit unclear to me why this is necessary at all.  Are we
> planning to support both the 4k and 64k guards?  My goal (once the guard
> was configurable) was never for supporting multiple sizes on a target
> but instead to allow experimentation to find the right default.
> 

I will get back to you on this one.

Thanks,
Tamar

> Jeff

-- 

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Jeff Law]

On 07/11/2018 05:22 AM, Tamar Christina wrote:
> Hi All,
> 
> This patch defines a configure option to allow the setting of the default
> guard size via configure flags when building the target.
> 
> The new flag is:
> 
>  * --with-stack-clash-protection-guard-size=
> 
> The value of configured based params are set very early on and allow the
> target to validate or reject the values as it sees fit.
> 
> To do this the values for the parameter get set by configure through CPP 
> defines.
> In case the back-end wants to know if a value was set or not the original 
> default
> value is also passed down as a define.
> 
> This allows a target to check if a param was changed by the user at configure 
> time.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no 
> issues.
> Both targets were tested with stack clash on and off by default.
> 
> Ok for trunk?
> 
> Thanks,
> Tamar
> 
> gcc/
> 2018-07-11  Tamar Christina  
> 
>   PR target/86486
>   * configure.ac: Add stack-clash-protection-guard-size.
>   * config.in (DEFAULT_STK_CLASH_GUARD_SIZE, STK_CLASH_GUARD_SIZE_DEFAULT,
>   STK_CLASH_GUARD_SIZE_MAX, STK_CLASH_GUARD_SIZE_MIN): New.
>   * params.def (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE): Use it.
>   * configure: Regenerate.
>   * Makefile.in (params.list, params.options): Add include dir for CPP.
>   * params-list.h: Include auto-host.h
>   * params-options.h: Likewise.
> 
Something seems wrong here.

What's the purpose of including auto-host in params-list and
params-options?  It seems like you're putting a property of the target
(guard size) into the wrong place (auto-host.h).

It's also a bit unclear to me why this is necessary at all.  Are we
planning to support both the 4k and 64k guards?  My goal (once the guard
was configurable) was never for supporting multiple sizes on a target
but instead to allow experimentation to find the right default.

Jeff