Question about trigger exceptions and other types of exceptions occurring at the same time about riscv-debug-spec

[pdonahue-ventana]

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]

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!

[Wei-VV1995]

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]

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]

Thank you very much for your answer !

[Wei-VV1995]

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]

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]

Thank you very much for your answer !