This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFA/RFC] Stack clash mitigation patch 01/08 - V3
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Aug 2017 11:07:48 +0200
- Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 01/08 - V3
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <CAFiYyc2ZQvOy5eG2WMxjCisJ0ZgrKHnZw6d=5mieDAhLt2VRrQ@mail.gmail.com> <email@example.com>
On Tue, Aug 22, 2017 at 5:52 PM, Jeff Law <firstname.lastname@example.org> wrote:
> On 08/18/2017 08:01 AM, Richard Biener wrote:
>> On Mon, Jul 31, 2017 at 7:35 AM, Jeff Law <email@example.com> wrote:
>>> This patch introduces the stack clash protection options
>>> Changes since V2:
>>> Adds two new params. The first controls the size of the guard area.
>>> This controls the threshold for when a function prologue requires
>>> probes. The second controls the probing interval -- ie, once probes are
>>> needed, how often do we emit them. These are really meant more for
>>> developers to experiment with than users. Regardless I did go ahead and
>>> document them./PARAM
>>> It also adds some sanity checking WRT combining stack clash protection
>>> with -fstack-check.
>> diff --git a/gcc/params.c b/gcc/params.c
>> index fab0ffa..8afe4c4 100644
>> --- a/gcc/params.c
>> +++ b/gcc/params.c
>> @@ -209,6 +209,11 @@ set_param_value (const char *name, int value,
>> error ("maximum value of parameter %qs is %u",
>> + else if ((strcmp (name, "stack-clash-protection-guard-size") == 0
>> + || strcmp (name, "stack-clash-protection-probe-interval") == 0)
>> + && exact_log2 (value) == -1)
>> + error ("value of parameter %qs must be a power of 2",
>> + compiler_params[i].option);
>> set_param_value_internal ((compiler_param) i, value,
>> params, params_set, true);
>> I don't like this. Either use them as if they were power-of-two
>> (floor_log2/ceil_log2 as appropriate) or simply make them take
>> the logarithm instead (like -mincoming-stack-boundary and friends).
> Yes. I was torn on this for a variety of reasons, including the fact
> that I don't actually expect anyone to be mucking with those :-)
> Given we've already other stuff in log2 form, I'll use that -- it seems
> less surprising to me than using floor/ceil.
>> Both -fstack-clash-protection and -fstack-check cannot be turned
>> off per function. This means they would need merging in lto-wrapper.
>> The alternative is to mark them with 'Optimization' and allow per-function
>> specification (like we do for -fstack-protector).
> Do you have a strong preference here? I'd tend to go with tweaking
> lto-wrapper as we really don't want to have this stuff varying per-function.
Any reason? I see no technical one at least, it might break IPA assumptions
you make when instrumenting? I guess you just don't want to think about
the implications when mixing them (or mixing -fstack-clash-protection
> Presumably in lto-wrapper we just have to detect that both were enabled
> and do something sensible. We drop -fstack-check in toplev.c when both
> are specified, we could just as easily call that situation a fatal error
> in both toplev.c and lto-wrapper.c
So what happens if you LTO link Ada (-fstack-check) with C
The user is already allowed to (without LTO) specify things on a CU granularity.