Questions about the dcsr.dcause priority

[cyl943123]

Hello,

I'd like to clarify the dcause priority behavior in some special scenarios (assuming itrigger is not implemented):

If, in the same cycle, a trigger fires (for example, only the mcontrol6 trigger), an interrupt occurs, and a single step causes entry into Debug Mode, which cause will be reported in dcause?

Specifically, if an interrupt occurs during single stepping, according to the spec, Debug Mode is reentered immediately after the PC is changed to the trap handler. In this case, is the step with interrupt viewed as an asynchronous event with higher priority than a synchronous event (e.g., trigger)? Or is it considered as the step event, giving it the lowest priority in dcause?

Thanks!
Jack Li

[pdonahue-ventana]

Here are my assumptions about your question:

• dcsr.stepie=1 (because stepie=0 would cause the interrupt to be ignored and there wouldn't really be a question)
• mcontrol6 has action=1
• dpc=X and the external debugger resumes
• all traps are to M mode (and if any trap is delegated then any comment I have about mepc would just be sepc or whatever)
• mtvec=Y

There are two possibilities:

1. There was an interrupt that is pending and enabled when you resume. Or, more precisely, the implementation takes an interrupt trap before executing X (which could be due to the interrupt becoming pending sometime after you resume and before it has committed to executing X). If you trap before executing X then you'll write mepc=X and update mtval, etc. Because there was a trap, we'll reenter debug mode immediately with dpc=Y and will execute neither X nor Y. Because no instruction executed, no mcontrol6 trigger matched so this presumably isn't the scenario you're talking about.
2. There was not an interrupt that was pending and enabled at the time that you resume but it becomes pending and enabled at some point after it has committed to executing X. For example, X writes to mie or mstatus.MIE or an interrupt wire asserts after you execute this instruction. In this case, you'll execute X because either you must (the mie or mstatus.MIE case) or because the instruction execution won the race against the interrupt wire. The interrupt doesn't really matter here so I don't think that this is the scenario you're talking about, either.

Can you give a more precise scenario?

[cyl943123]

Hello,

Thank you for your thorough analysis!

I'd like to clarify the behavior further regarding race conditions:

Suppose, after resuming from Debug Mode (with single-step enabled), we have:

An mcontrol6 trigger (timing = "before") configured at the PC of instruction X
An interrupt (pending and enabled) occurs exactly in the same cycle as the trigger fires for instruction X
To be precise, this scenario is at the moment before instruction X has committed.

In this case, which event takes priority for entering Debug Mode?
More specifically, should dcause record the trigger event, or the step event as the cause in this situation?

Is there any guidance or requirement from the spec on prioritizing synchronous trigger events vs asynchronous interrupt traps, or is this left as implementation-defined?

Thanks for your insights!
Jack Li

[pdonahue-ventana]

Architecturally, everything must follow the sequential execution model where interrupts happen between instructions, not during instructions.¹ Consider the situation where there is no debugger at all and you have an instruction page fault and an interrupt at the same time. You can only take one trap at a time so you either have to:

1. Take the page fault trap and then evaluate whether you're allowed to take the interrupt before executing the first instruction of the page fault handler (i.e. page fault wins the race with the interrupt).
2. Take the interrupt and behave as if instruction X didn't execute at all (i.e. the interrupt wins the race with the page fault).

If we change page fault to be mcontrol6 with action=0 then you have the same choices:

1. Take the breakpoint trap and then evaluate whether you're allowed to take the interrupt before executing the first instruction of the breakpoint handler (i.e. mcontrol6 wins the race with the interrupt).
2. Take the interrupt and behave as if instruction X didn't execute at all (i.e. the interrupt wins the race with mcontrol6).

The exact same choices exist in your scenario. You either have to:

1. Take the trigger (halt) if the interrupt loses the race. No instruction was executed and no trap happened so there was no step. The cause must be the trigger.
2. Take the interrupt if the interrupt wins the race. This means that you'll set mepc=X and enter debug mode with dpc=Y (or maybe Y plus some offset if you're in vectored mode). The cause must be the step because there was no trigger (because it must behave as if X didn't execute at all).

Footnotes

1. I'm glossing over the allowed behavior of some vector instructions. On those instructions, we can similarly say that interrupts happen between elements, not during elements. ↩