This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Fri, 14 Jul 2017 11:49:52 +0000
- Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08
- Authentication-results: sourceware.org; auth=none
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <AM5PR0802MB2610577C26553C3E7C2B8FCC83AE0@AM5PR0802MB2610.eurprd08.prod.outlook.com>,<20170714081719.GY2123@tucnak>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Jakub Jelinek wrote:
> On Wed, Jul 12, 2017 at 12:20:32AM +0000, Wilco Dijkstra wrote:
> > Therefore even when using a tiny 4K probe size we can safely adjust SP by 3KB
> > before needing an explicit probe - now only 0.6% of functions need a probe.
> > If we choose a proper minimum probe distance, say 64KB, explicit probes are
> > basically non-existent (just 35 functions, or ~0.02% of all functions are > 64KB).
> > Clearly inserting probes can be the default as the impact on code quality is negligible.
>
> For non-leaf functions you need at least one probe no matter how small the
> frame size is (if it is bigger than 0), explicit or implicit, unless you
> perform IPA analysis on the callgraph and determine when that isn't needed,
> because you can have deep call stacks that would through functions that
> don't touch anything skip stack pages. Of course, such probes can be stores
> of call used registers, it can be any store to the stack.
Well you need to save the return address somewhere, so a non-leaf function already
has an implicit probe before a call (even if shrinkwrapped). So it is not possible for a
long sequence of function calls or a recursive function to jump the stack guard - the
only way to jump the guard is using a huge unchecked static or dynamic allocation.
One key thing to understand is that it doesn't matter where exactly the return address
is saved in a frame. You could save it at a random location and all it would mean is that
if the probe size is N, you only need to insert additional explicit probes if the frame is
larger than N/2 (sum of static and dynamic allocation). Obviously you could do better
than that with a well defined frame layout.
Before we consider IPA, how about optimizing trivial alloca's first? For example why
does GCC emit dynamic allocations for:
void f(void*);
void alloca (int x)
{
if (x < 100)
f (__builtin_alloca (x));
f (__builtin_alloca (16));
}
Wilco