Re: [PATCH][RFA/RFC] Stack clash mitigation patch 01/08 - V3

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Aug 22, 2017 at 5:52 PM, Jeff Law <law@redhat.com> wrote:
> On 08/18/2017 08:01 AM, Richard Biener wrote:
>> On Mon, Jul 31, 2017 at 7:35 AM, Jeff Law <law@redhat.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",
>>     compiler_params[i].option,
>>     compiler_params[i].max_value);
>> +  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);
>>    else
>>      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
with -fno-stack-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
(-fstack-clash-protection)?

The user is already allowed to (without LTO) specify things on a CU granularity.

Richard.
>
> jeff
>
>