This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Jeff Law <law at redhat dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Cc: nd at arm dot com, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Mon, 27 Nov 2017 15:48:41 +0000
- Subject: Re: [RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <3a6b1bdf-df0f-a512-fd2b-116d57702bc7@redhat.com> <DB6PR0801MB205342840273A485E44D16D783480@DB6PR0801MB2053.eurprd08.prod.outlook.com> <dc1452bb-69af-4c3a-b08c-dbb0a6f219da@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 28/10/17 05:08, Jeff Law wrote:
> On 10/13/2017 02:26 PM, Wilco Dijkstra wrote:
>> For larger frames the first oddity is that there are now 2 separate params
>> controlling how probes are generated:
>>
>> stack-clash-protection-guard-size (default 12, but set to 16 on AArch64)
>> stack-clash-protection-probe-interval (default 12)
>>
>> I don't see how this makes sense. These values are closely related, so if
>> one is different from the other, probing becomes ineffective/incorrect.
>> For example we generate code that trivially bypasses the guard despite
>> all the probing:
> My hope would be that we simply don't ever use the params. They were
> done as much for *you* to experiment with as anything. I'd happy just
> delete them as there's essentially no guard rails to ensure their values
> are sane.
so is there a consensus now that 64k guard size is what
gcc stack probing will assume?
if so i can propose a patch to glibc to actually have
that much guard by default in threads.. (i think it
makes sense on all 64bit targets to have bigger guard
and a consensus here would help making that change)
>> Also on AArch64 --param=stack-clash-protection-probe-interval=16 causes
>> crashes due to the offsets used in the probes - we don't need large offsets
>> as we want to probe close to the bottom of the stack.
> Not a surprise. While I tried to handle larger intervals, I certainly
> didn't test them. Given the ISA I wouldn't expect an interval > 12 to
> be useful or necessarily even work correctly.
it's not clear what makes probing at every 64k hard,
i think this should be clarified before we stick to
this design. (..or before backporting such patches)