This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]
- From: Tamar Christina <Tamar dot Christina at arm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>, "bonzini at gnu dot org" <bonzini at gnu dot org>, "dj at redhat dot com" <dj at redhat dot com>, "neroden at gcc dot gnu dot org" <neroden at gcc dot gnu dot org>, "aoliva at redhat dot com" <aoliva at redhat dot com>, "Ralf dot Wildenhues at gmx dot de" <Ralf dot Wildenhues at gmx dot de>
- Date: Thu, 12 Jul 2018 18:45:04 +0100
- Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]
- References: <20180711112233.GA15865@arm.com> <firstname.lastname@example.org>
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=<num>
> > 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 <email@example.com>
> > 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
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.