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. Bye, -Andreas-
