-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
For interrupt and exception triggers with action = 0, what value for mcause? #890
Comments
If a trap is taken to M mode (either due to an exception or interrupt) then it normally has these effects:
Per section 5.4, item 3 and/or 4 should cause the itrigger/etrigger to not fire (since these triggers are defined to happen after the trap). This is also mentioned in non-normative text: "Both options prevent etrigger and itrigger from having any effect on exceptions and interrupts that are handled in M-mode." Since the itrigger/etrigger doesn't fire, mcause should behave as required in the priv spec. |
I agree this is confusing. I don't see the language that Paul references from Section 5.4. I think what the existing text is trying to say is: When the trigger fires:
|
https://github.com/riscv/riscv-debug-spec/blob/master/Sdtrig.tex#L239 |
Fair enough, but that's just a conclusion in a commentary. I think we can be more clear about this. Do you agree with my 2-step interpretation above? If so, I can turn it into a PR. |
5.4 says "Harts that support triggers with action =0 should implement one of the following two solutions..." If a hart does not follow that recommendation then I agree with your 2-step interpretation. If a hart does follow that recommendation then only your first step applies and the second step is skipped. |
I don't understand how this solves the problem originally raised by this issue. If an exception trigger has m = 1 and action = 0, it may fire when executing in M mode, and then the question remains, what value does the hardware write to |
You quoted the "If a hart does follow that recommendation" line so I'm assuming that your question is about that. If a hart does follow that recommendation then it is impossible for an exception trigger with action=0 to fire when executing in M mode. See my first comment above for what will happen. If your question is about a hart that doesn't follow that recommendation then presumably the hart writes mcause for the original exception, then the etrigger fires and the and the hart writes mcause=3 and mepc=mtvec (just as it would have written mcause=3 and mepc=stvec if the etrigger fired on a trap to S/HS mode). Note that the debugger will not be able to resume execution if the hart doesn't follow that recommendation so this whole mechanism is not very useful except in desperation. |
Okay, sorry, I think I get it now. But we agree the spec still needs clarification for the case that a hart "does not follow that recommendation". |
Specifically, make clear that itrigger fires *after* the original exception has finished updating all the CSRs. Hopefully resolves #890.
Specifically, make clear that itrigger fires *after* the original exception has finished updating all the CSRs. Hopefully resolves #890.
Yes. #901 will address this concern. |
Specifically, make clear that itrigger fires *after* the original exception has finished updating all the CSRs. Hopefully resolves #890.
Hello @pdonahue-ventana |
The spec says, "The hardware prevents triggers with action=0 from matching or firing while in M-mode * Hidden architectural state is generally a bad idea. |
Hi @pdonahue-ventana Thanks for response.
In my M-mode ecall trap handler, mstatus.MIE and tcontrol.MTE are always 0, until mret to U-mode. |
etrigger and itrigger will never fire in a M+U hart or in a M-only hart because all exceptions and interrupts are handled in M mode. "Both options prevent etrigger and itrigger from having any effect on exceptions and interrupts that are handled in M-mode." If your handler is not ROM, try this: "Debuggers should use other mechanisms to debug these cases, such as patching the handler..." Or use an external debugger (which is normally how you'd have to debug a hart where the handlers are in ROM). |
Now I understand it. Thank you! |
Section 5.6.14, "Interrupt Trigger", says:
If a trigger fires on an interrupt trap that is taken into M mode, and
itrigger
.action = 0, what value is required to end up in themcause
CSR? To indicate a breakpoint exception, it needs to be the value 3, but the quoted text suggests it will rather be the value that the interrupt handler would normally see.Much the same question arises in the next subsection, "Exception Trigger", which has almost identical text. If a trigger fires on an exception trap that is taken into M mode, and
etrigger
.action = 0, what value is required to be in themcause
CSR? Is it 3 for the breakpoint exception, or is it the code for the exception that caused the trigger to fire?Note, if the answer for an exception trigger is 3, then the cause code for the original triggering exception is lost, unless the trigger is configured with only one bit set in
tdata2
(or the subset of possible exception causes can be proved to be a singleton by some other means).The text was updated successfully, but these errors were encountered: