Add pending state/bit to icount.#574
Conversation
See mailing list. Subject:"On icount triggers"
|
This was also discussed in #559 |
Conflicts: xml/hwbp_registers.xml
| M-mode decrements \FcsrIcountCount by 1. | ||
| When set, enable this trigger in M-mode. | ||
| </field> | ||
| <field name="pending" bits="8" access="R/W" reset="0"> |
There was a problem hiding this comment.
Does this bit need to be writable?
There was a problem hiding this comment.
Might there be a need to context-switch this register? I didn't think too hard about it but it seems like that might happen.
There was a problem hiding this comment.
My thought was that an M-mode debugger might want to clear the bit for some reason, and surely somebody might have a clever use for setting it. I don't think it costs the hardware anything to make it writable given that it already exists, so I made it writable. If I'm wrong about hardware and making the bit writable makes implementations notably more complicated, I'm fine with it being read-only.
| M-mode decrements \FcsrIcountCount by 1. | ||
| When set, enable this trigger in M-mode. | ||
| </field> | ||
| <field name="pending" bits="8" access="R/W" reset="0"> |
There was a problem hiding this comment.
Might there be a need to context-switch this register? I didn't think too hard about it but it seems like that might happen.
| \FcsrIcountCount by 1, unless \FcsrIcountAction is 0, the current | ||
| mode is M-mode, and M-mode breakpoints are disabled via one of the | ||
| mechanisms described in Section~\ref{sec:mmtrigger}. When |
There was a problem hiding this comment.
After this change introducing the pending bit, I wonder if this is even necessary anymore. I had suggested this behavior since otherwise the breakpoint exception would get lost when the count reached 0 and exceptions were blocked. But now with the pending bit, that exception would not get lost anymore.
There was a problem hiding this comment.
I don't quite follow you. I thought pending is orthogonal to the mechanisms that might disable triggers in M-mode. Can you explain a bit more what you mean?
There was a problem hiding this comment.
This change (to stop count decrementing when exceptions were blocked) was #555. I opened that issue because at the time, if count decremented to 0 and breakpoint exceptions were blocked, the breakpoint would get dropped on the floor and never taken. Stopping the decrementing when exceptions were blocked was a way to avoid dropping that breakpoint exception completely.
But now, with this new pending bit, if the count still decrements even when exceptions are blocked, the pending bit will turn on and stay on until the exception can be taken, so it will no longer get dropped on the floor.
So I think #555 is moot and should be undone.
There was a problem hiding this comment.
I agree. There is maybe some use to disabling counting while in M-mode, but it makes the language more cumbersome and presumably the implementation as well. For the single step case #555 is no longer needed, and I cannot really imagine why somebody would want to count M-mode instructions except the ones executed while M-mode triggers are enabled.
4 participants
See mailing list. Subject:"On icount triggers"