[PATCH][RFA/RFC] Stack clash mitigation patch 04/08 V2

2017-07-18 Thread Jeff Law
I don't think this has changed in any significant way since V1. -- This patch introduces x86 target specific bits to mitigate stack clash attacks. The key differences relative to the -fstack-check=specific expander are that it never allocates more than PROBE_INTERVAL bytes at a time, it probes

[PATCH][RFA/RFC] Stack clash mitigation patch 05/08

2017-07-18 Thread Jeff Law
I don't think this has changed in any significant way since V1. -- The prior patch introduced -fstack-clash-protection prologues for the x86. And yet we still saw large allocations in our testing. It turns out combine-stack-adjustments would take allocate PROBE_INTERVAL probe allocate

[PATCH][RFA/RFC] Stack clash mitigation patch 06/08 V2

2017-07-18 Thread Jeff Law
These are the PPC bits for stack clash mitigation. As noted before the PPC bits were larger/more complex than other ports. Part of that was due to the PPC defining its own dynamic stack allocation expander -- which in turn means we weren't using any of the generic code in explow.c for stack

[PATCH][RFA/RFC] Stack clash mitigation patch 02b/08 V2

2017-07-18 Thread Jeff Law
-fstack-clash-protection is now separate from -fstack-check=. But we still want targets without stack-clash specific prologue support to be able to get partial coverage from -fstack-clash-protection. This adds the necessary checks for flag_stack_clash_protection to the appropriate targets so we

[PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2

2017-07-18 Thread Jeff Law
The biggest change since V1 of this patch is dropping the changes to STACK_CHECK_MOVING_SP. They're not needed. This patch also refactors a bit of the new code in explow.c. In particular it pulls out 3 chunks of code for protecting dynamic stack adjustments so they can be re-used by backends

[PATCH][RFA/RFC] Stack clash mitigation patch 03/08 V2

2017-07-18 Thread Jeff Law
I don't think this patch changed in any significant way since V1. -- One of the painful aspects of all this code is the amount of target dependent bits that have to be written and tested. I didn't want to be scanning assembly code or RTL for prologues. Each target would have to have its own

[PATCH][RFA/RFC] Stack clash mitigation patch 01/08 V2

2017-07-18 Thread Jeff Law
The biggest change in this update to patch 01/08 is moving of stack clash protection out of -fstack-check= and into its own option, -fstack-clash-protection. I believe other issues raised by reviewers have been addressed as well. -- This patch introduces a new option -fstack-clash-protection

[PATCH][RFA/RFC] Stack clash mitigation patch 08/08 V2

2017-07-18 Thread Jeff Law
I don't think this patch has changed in any significant way since the V1 patch. I have tested a slightly different version which punts stack clash protection for very large static stack frames -- otherwise tests which have *huge* frames will timeout, run out of memory during compilation, etc. --

[PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2

2017-07-18 Thread Jeff Law
This time with the patch attached. Forwarded Message Subject: [PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2 Date: Tue, 18 Jul 2017 23:17:23 -0600 From: Jeff Law To: gcc-patches The biggest change since V1 of this patch

<    1   2