Conversation
This makes it possible to use triggers to debug some of the exception handling code as well. See 2022 email subject:"trigger questions"
|
This seems like it's not backwards compatible. I think that a note should be added to 1.2.1.5. |
|
Huh. I'd written that but not pushed it up yet. Here it is. |
|
The e-mail thread about this really starts at https://lists.riscv.org/g/tech-debug/topic/89848254#691. This change solves some problems when stepping into exception handlers when native debugging the highest privilege mode. (This is really the ideal use case for external debug, but we try to accommodate native debugging here as well.) If every trap into M-Mode clears mte, then you can't use icount triggers to step into an exception handler. By limiting this clearing to breakpoint exceptions only, more code can be debugged. |
|
AR feedback is that this change results in the mechanism not serving its purpose when non-breakpoint traps occur. That sounds right to me. Consider:
@pdonahue-ventana can you look this over? You have a gift for corner cases. |
Reverts #723, which would result in mepc etc. being clobbered if a breakpoint trigger would fire in the most privileged mode. Specifically, consider: 1. icount is set so that it'll trigger on the first instruction of an exception handler. 2. Code takes an exception, saving mepc etc. 3. Now icount fires causing a breakpoint exception, clobbering mepc.
Reverts #723, which would result in mepc etc. being clobbered if a breakpoint trigger would fire in the most privileged mode. Specifically, consider: 1. icount is set so that it'll trigger on the first instruction of an exception handler. 2. Code takes an exception, saving mepc etc. 3. Now icount fires causing a breakpoint exception, clobbering mepc.
2 participants
This makes it possible to use triggers to debug some of the exception
handling code as well.
See 2022 email subject:"trigger questions"