On 01/31/2018 01:28 AM, Eric Botcazou wrote: >> -fstack-check and -fstack-clash both potentially create a loop for stack >> probing. In that case they both need a scratch register to hold the >> loop upper bound. >> >> The code to allocate a scratch register first starts with the >> caller-saved registers as they're zero cost. Then it'll use any callee >> saved register that is actually saved. If neither is available (say >> because all the caller-saved regs are used for parameter passing and >> there are no callee saved register used), then the allocation routine >> will push %eax on the stack and the deallocation routine will pop it off >> to restore its value. >> >> Of course there is a *stack allocation* between those two points. So >> the pop ends up restoring garbage into the register. > > There is a stack allocation only on Linux, there isn't any on Solaris, *BSD, > Windows, LynxOS and other OSes where you can probe below the stack pointer. So I went back and restored the code for targets that don't define STACK_CHECK_MOVING_SP (everything but linux I believe).
To test it I turned on stack checking by default, bootstrapped that as a baseline. Then I turned off STACK_CHECK_MOVING_SP, compared that to the baseline. Not surprisingly, things with large stacks failed during probing. I then hacked up the dejagnu bits to present just an 8k stack which made all the regressions which had stack usage dg markers turn into UNRESOLVED. There were still many tests that had to be checked manually because they didn't have stack usage dg markup. This is baseline #2. I then forced all prologue allocations to go through the loop code, bootstrapped that and compared it to baseline #2. Then I turned off STACK_CHECK_MOVING_SP and forced all prologue allocations to go through the loop code. Bootstrapped that and compared the results to the baseline to ensure we weren't regressing. Note some tests want to verify we don't have push/pops in their resulting assembly code or count the number of orl instructions. Those had to be hand-checked along the way as well. Par for the course. I'm confident I've got all 3 paths covered reasonably well now. I still need to check into the CFI concern before resubmitting. jeff ps. I also did light testing before restoring the code to handle !STACK_CHECK_MOVING_SP to verify that it indeed was wrong with my original patch.
