This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] [ARC] Fix and refurbish the interrupts.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]