-
Notifications
You must be signed in to change notification settings - Fork 93
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
Tell external debugger whether mcontrol6.hit bits are supported #1080
Comments
@JanMatCodasip, thank you for the proposal! I'm also deeply concerned by the current state of I have a couple of comments:
Hit bits should be cleared by SW (only SW knows when it got all the necessary info), so at least the
I don't get what it means in case of a read-only field. |
There is also an alternative solution to deriving support of When setting the trigger check if the desired timing is the only one supported (based on Table 15. Suggested Trigger Timings) by looping through There are a number of benefits to this approach:
vs
There is a caveat -- nothing prevents |
@en-sc, thank you for your replies.
I was thinking that hit bits could be read-only and reflect the current state - the state at the moment of last halt. This would be similar to the behavior of But anyway, that would be just an unrelated side-improvement, and I don't feel strongly about it.
You're right, that sentence does not make too much sense. I have removed it from my original comment.
Thank you for mentioning that approach. I expect it will work for virtually all existing targets. That is, I am not too worried about the caveat you mentioned (it is technically possible, but in my opinion very improbable in practice). |
But what about other actions (e.g. breakpoint exception or start tracing)? Native (self-hosted) debugger has no equivalent to writing |
@en-sc, you're right, I forgot about other trigger actions than "enter debug mode". I have removed the sentence about making |
The traditional answer to these kinds of questions has been that it could go in the https://github.com/riscv/configuration-structure. That project seems to have moved away from describing implementation details like this, but it might be added before Debug 1.1 happens. |
The 1.0 version of the debug specification gives a lot of freedom to the trigger implementers if and how to implement support for
mcontrol6.hit{0,1}
bits. At the same time it is not clearly reported back to the external debugger if hit bits are supported.As an extreme case, the current version of the spec permits that a given mcontrol6 trigger supports the hit bits for certain combination of fields of mcontrol6 and but does not support them for other combination of the fields of that very same trigger.
For these reasons, it is difficult for the external debugger to distinguish what
hit[1:0] == 0b00
actually means:In order to reliably tell these two cases apart, the external debugger currently needs to perform a lengthy procedure:
With the above in mind, I propose that 1.1 version of the spec introduces a clear mechanism that will tell external debuggers whether mcontrol6.hit bits are supported in the hardware.
I can think of these options:
Option 1: Make
mcontrol6.hit
bits mandatory for all trigger implementations and incrementtinfo.version
.Option 2: Introduce new
mcontrol6.hit2
bit which would allow to encode all the outcomes below.Don't allow partial implementation of some but not all of the hit bits.Make the hit bits read only, similarly toIncrementdcsr.cause
.tinfo.version
.What is your opinion on this? Thank you.
The text was updated successfully, but these errors were encountered: