Re: [PATCH][RFA] Fix -fstack-check with really big frames on aarch64

[Jeff Law <law at redhat dot com>]

On 06/22/2017 11:07 AM, Jakub Jelinek wrote:
> On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
>> On Jun 22, 2017, at 8:32 AM, Jeff Law <law@redhat.com> wrote:
>>>
>>> Sure.  I'll do something with 20031023-1.c to ensure it or an equivalent
>>> is compiled with -fstack-check.  That isn't totally unexpected.   I
>>> would have also been receptive to adding -fstack-check to the torture flags.
>>
>> Ouch.  Though stack checking might be important, the feature is very, very
>> narrow, and once tested, if unlike to ever break or interact badly with
>> other work.  I'd rather people default it to on, run the entire suite, fix
>> all bugs (with test cases added for all the bugs), then turn it back off. 
>> Additional torture passes are expensive; we use them for things that do
>> regress, that are important, that have thousands of moving parts to keep
>> them working.  O2, -g are good examples for things that by their nature,
>> likely will always be best served by torture options.  Now, if you want to
>> focus on security for 1-3 months, add it, fix all the bugs, then turn it
>> off; it would be a great way to get all the bugs filed, if you want.
> 
> Yeah, I think it should be enough to have one or a couple of -fstack-check
> covering testcases in the testsuite, with 10-20 different static frame sizes
> (a couple of leaf functions and then functions that call something) and then
> for each also variant with alloca or VLA, make it executable and test you
> can store stuff in the buffers and read it back in some other function,
> compile this with -fno-omit-frame-pointer, -fomit-frame-pointer and default.
> No need to torture everything with it.
I expect we'll want to do a bit more than that -- in particular if we
look at how prologues as generated on aarch64, we'll want to test each
of the paths  through there which allocate stack space and verify that
the proper probes are emitted or omitted.

The thought of scanning the assembly code or RTL is too painful to
contemplate.  THus I've been pondering having the prologue expanders
emit notes into the dump file about what they did and why WRT probing.

Or maybe we should use the unit testing framewhere here.  Hmmm....


jeff