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 08/08
- From: Jeff Law <law at redhat dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 14 Jul 2017 08:55:15 -0600
- Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 08/08
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C45167853D
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C45167853D
- References: <c9c1cb38-de11-3ab9-88f1-de4044f5d01e@redhat.com> <b6083797-a808-94f0-83e3-fd254eb35a54@linux.vnet.ibm.com>
On 07/14/2017 08:29 AM, Andreas Krebbel wrote:
> On 07/11/2017 11:21 PM, Jeff Law wrote:
>> This patch adds s390 support for stack-clash mitigation.
>>
>> s390's most interesting property is that the caller allocates space for
>> the callee to save registers into.
>>
>> So much like aarch64, we start with a very conservative assumption about
>> the offset between SP and the most recent stack probe. As we encounter
>> those register saves we may be able to decrease that offset. And like
>> aarch64 as we allocate space, the offset increases. If the offset
>> crosses PROBE_INTERVAL, we must emit probes.
>>
>> Because the register saves hit the caller's frame s390 in some ways
>> generates code more like x86/ppc. Though if there aren't any register
>> saves, then the resulting code looks more like aarch64.
>>
>> For large frames, I did not implement an allocate/probe in a loop.
>> Someone with a better understanding of the architecture is better suited
>> for that work. I'll note that you're going to need another scratch
>> register :-) This is the cause of the xfail of one test which expects
>> to see a prologue allocate/probe loop.
>>
>> s390 has a -mbackchain option. I'm not sure where it's used, but we do
>> try to handle it in the initial offset computation. However, we don't
>> handle it in the actual allocations that occur when -fstack-check=clash
>> is enabled.
>>
>> s390 does not have a -fstack-check=specific implementation. I have not
>> tried to add one. But I have defined STACK_CHECK_STATIC_BUILTIN. I
>> haven't investigated what side effects that might have.
>>
>> Other than the xfail noted above, the s390 uses the same tests as the
>> x86, ppc and aarch64 ports.
>>
>> I suspect we're going to need further iteration here.
>>
>> Thoughts/Comments?
>
> I'll have a look and run some tests to come back with an answer next week.
Thanks. That'd be greatly appreciated.
Jeff