On 7/8/19 2:35 AM, Claudiu Zissulescu wrote: > Hi Jeff, > > Originally, I had the scheduler barrier as you suggested. However, > there were some user cases when an ISR messed up with SP register > leading to errors. As a solution was to add barriers on either part of > frame operations. However, I would need to recheck the original > rationale of that issue, as it may not be the case with newer cores. For the prologue ISTM that the only issue would be if you had a store via the frame pointer that moved to a point before allocating the stack. I don't think we've ever seen that in practice though.
In the epilogue, the case we've seen several times is we have register restores via the frame pointer move to a point before deallocating the stack. In both cases there'd be live data that would be out of the bounds of the current stack pointer. THus if an interrupt occurred the handler could stomp on that data. > > On the other hand, I found a small error of the current patch when one > is having the fno-omit-frame-pointer option in the order how some > auxiliary registers are saved. What will be the best solution having > in mind that I haven't pushed this patch to the mainline yet: > - to have the current patch re-spin? > - to have a separate patch for the new issue. Your decision. Jeff
