On 09/21/2017 02:38 AM, Rainer Orth wrote: > Jeff Law <l...@redhat.com> writes: > >> This patch introduces the x86 stack clash protected prologue support as >> well as the tests. I believe the only change since V3 was the more >> aggressive introduction of scheduling barriers. It also enables the >> stack-clash tests for x86 targets. >> >> The scheduling barriers prevent the memory dependency breaking bits in >> the scheduler from rewriting and rearranging the allocations and probes. >> While I haven't seen problems from that on x86, I did see the scheduler >> muck things up on aarch64 and there's a test for that in the aarch64 >> specific patches. Better to be safe here and just emit the scheduling >> barriers. >> >> Bootstrapped and regression tested on x86. Installing on the trunk. >> >> Jeff >> >> commit 57e17e31cb358fcd0d7cea8264b5063762ab3971 >> Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4> >> Date: Wed Sep 20 05:35:07 2017 +0000 >> >> * config/i386/i386.c (ix86_adjust_stack_and_probe_stack_clash): >> New. >> (ix86_expand_prologue): Dump stack clash info as needed. >> Call ix86_adjust_stack_and_probe_stack_clash as needed. >> >> * gcc.dg/stack-check-4.c: New test. >> * gcc.dg/stack-check-5.c: New test. >> * gcc.dg/stack-check-6.c: New test. >> * gcc.dg/stack-check-6a.c: New test. >> * gcc.dg/stack-check-7.c: New test. >> * gcc.dg/stack-check-8.c: New test. >> * gcc.dg/stack-check-9.c: New test. >> * gcc.dg/stack-check-10.c: New test. >> * lib/target-supports.exp >> (check_effective_target_supports_stack_clash_protection): Enable >> for >> x86 and x86_64 targets. > > Some of the new tests FAIL on Solaris/x86: > > +FAIL: gcc.dg/stack-check-10.c scan-rtl-dump-times pro_and_epilogue "Stack > clash no frame pointer needed" 2 > +FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue "Stack > clash no frame pointer needed" 4 > +FAIL: gcc.dg/stack-check-6.c scan-rtl-dump-times pro_and_epilogue "Stack > clash no frame pointer needed" 4 > +FAIL: gcc.dg/stack-check-6a.c scan-rtl-dump-times pro_and_epilogue "Stack > clash no frame pointer needed" 4 > +FAIL: gcc.dg/stack-check-9.c scan-rtl-dump-times pro_and_epilogue "Stack > clash no frame pointer needed" 1 > > for both 32 and 64-bit, all are guarded by ! frame_pointer_for_non_leaf. > > frame_pointer_for_non_leaf currently only true for aarch*-*-*, but > i386/sol2.h has > > #define USE_IX86_FRAME_POINTER 1 > #define USE_X86_64_FRAME_POINTER 1 > > unlike i386/i386.c where both are 0 by default. Fixed with the > following patch: Yea. We're probably going to need that patch. I'll roll it into whatever I do for -10 and -5.
> > > > > +FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times orq 3 > +FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times subq 4 > > 32-bit only, generic 32-bit x86, already fixed, I believe. Correct. > > The following are 64-bit only and remain even after the > frame_pointer_non_leaf fix: > > +FAIL: gcc.dg/stack-check-10.c scan-rtl-dump-times pro_and_epilogue "Stack > clash residual allocation in prologue" 2 > > +FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue "Stack > clash no residual allocation in prologue" 1 > +FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue "Stack > clash residual allocation in prologue" 3 These are related to frame pointer handling as well, but are somewhat different. THe good news is we're generating the right code -- it's just a matter of properly dumping and testing the dumps correctly. Which will likely always be somewhat problematical for prologues... Anyway, I'm going to poke at -10 and -5 to see how best to approach. jeff > > Rainer >
