-
Notifications
You must be signed in to change notification settings - Fork 95
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
Question about trigger exceptions and other types of exceptions occurring at the same time #1056
Comments
Supporting execute triggers with timing=after is a bad idea. If you have an execute trigger with timing=after and an illegal instruction then the illegal instruction is the highest priority according to table 13. You take the trap, update mepc, and go to mtvec. Then the "mcontrol/mcontrol6 after (on previous instruction)" would be the highest priority on the first instruction of the handler. Because MIE=0, this trigger would not fire and the trigger is completely lost (since there is no pending bit). If you had timing=before then "mcontrol/mcontrol6 execute address before" would have higher priority than illegal instruction and mepc would point to the current instruction (which has not yet executed and gone to the illegal instruction handler). This is obviously much more desirable. |
Thanks for your explanation. I don't quite understand the phrase "Because MIE=0, this trigger would not fire and the trigger is completely lost (since there is no pending bit)" in your answer. What is the relationship between MIE and trigger? Any help would be greatly appreciated! |
1 similar comment
Thanks for your explanation. I don't quite understand the phrase "Because MIE=0, this trigger would not fire and the trigger is completely lost (since there is no pending bit)" in your answer. What is the relationship between MIE and trigger? Any help would be greatly appreciated! |
See section 5.4 ("Native Triggers") in the spec. I was assuming that you'd implement this MIE option but if you implement the mte option then I would have said the exact same thing except using "mte=0" instead of "MIE=0". |
Thank you very much for your answer ! |
Thanks for your explanation. |
MIE generally indicates whether a handler is reentrant or not. If a handler has MIE=1 then it definitely can tolerate a trap happening. If a handler has MIE=0 then it probably cannot (though maybe it can). MIE is the only thing that acts like this and, although it may be overly conservative, it will guarantee that triggers don't cause traps that do not allow us to eventually get back to normal execution. Alternatively, we could have done something like Smdbltrp/Ssdbltrp did by adding MDT and SDT bits to mstatus. But that involved changing a CSR that's generally outside the scope of the debug TG. Option 2 of using mte is similar to MDT but it has limitations and it requires context switch code to deal with another CSR. |
Thank you very much for your answer ! |
Hi All,
Set the trigger type to: tdata1.type=mcontrol6,tdata1.execute,timing is after。
The pc with the trigger exception set is also an illegal instruction, and the trigger exception should be handled according to the priority. So should mepc be updated to the current instruction pc or the next instruction pc?
Any help would be greatly appreciated!
The text was updated successfully, but these errors were encountered: