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
