Skip to content
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

Open
Wei-VV1995 opened this issue Jul 15, 2024 · 8 comments

Comments

@Wei-VV1995
Copy link

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!

@pdonahue-ventana
Copy link
Collaborator

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.

@Wei-VV1995
Copy link
Author

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
@Wei-VV1995
Copy link
Author

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!

@pdonahue-ventana
Copy link
Collaborator

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?

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".

@Wei-VV1995
Copy link
Author

Thank you very much for your answer !

@Wei-VV1995
Copy link
Author

Thanks for your explanation.
In general, mstatus.mie is a switch used to determine whether to respond to interrupts. In the debug spec, MIE is also used to control whether to respond to trigger exceptions. What is the significance of controlling trigger exception response through MIE?

@pdonahue-ventana
Copy link
Collaborator

What is the significance of controlling trigger exception response through MIE?

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.

@Wei-VV1995
Copy link
Author

Thank you very much for your answer !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants