This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On June 22, 2017 7:17:16 PM GMT+02:00, Jeff Law <> wrote:
>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 <> wrote:
>>>> Sure.  I'll do something with 20031023-1.c to ensure it or an
>>>> 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
>>> 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
>>> Additional torture passes are expensive; we use them for things that
>>> regress, that are important, that have thousands of moving parts to
>>> them working.  O2, -g are good examples for things that by their
>>> 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
>> 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
>> can store stuff in the buffers and read it back in some other
>> compile this with -fno-omit-frame-pointer, -fomit-frame-pointer and
>> 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....

I've been thinking that for Linux the kernel should have a way (/proc/pid controlled) to only extend the stack mapping for faults to the page exactly below the current end of the mapping.  So we'd get a segfault for any missed probe.

Just for QA purposes of course, I expect too many false positives in a full system.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]