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

[Jakub Jelinek <jakub at redhat dot com>]

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.

	Jakub