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
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
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
-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
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
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
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
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.
--
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
101 - 109 of 109 matches
Mail list logo