You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a debugger tries to perform an abstract access and that access fails, the failure is captured in abstractcs.cmderr. If it fails for more than one reason, the priority isn't specified. For instance, if a hart is not halted and the debugger tries to perform an unsupported operation then are we supposed to see cmderr=2 (not supported) or cmderr=4 (halt/resume)? Or if the hart is not halted and the requested register does not exist in the hart then do we see cmderr=3 (exception) or cmderr=4?
A real debugger probably doesn't care. For instance, if it accesses a non-existent register when not halted and it gets cmderr=4 then the debugger will likely halt the hart and try again, seeing cmderr=3. In the end, it will know that (a) it must halt to do abstract accesses and (b) that this register doesn't exist. If the implementation prioritized them in the opposite order then the debugger would still eventually come to the same conclusion.
I wanted to raise this concern but it's relatively minor and I don't think that this should derail the ratification process.
The text was updated successfully, but these errors were encountered:
If a debugger tries to perform an abstract access and that access fails, the failure is captured in abstractcs.cmderr. If it fails for more than one reason, the priority isn't specified. For instance, if a hart is not halted and the debugger tries to perform an unsupported operation then are we supposed to see cmderr=2 (not supported) or cmderr=4 (halt/resume)? Or if the hart is not halted and the requested register does not exist in the hart then do we see cmderr=3 (exception) or cmderr=4?
A real debugger probably doesn't care. For instance, if it accesses a non-existent register when not halted and it gets cmderr=4 then the debugger will likely halt the hart and try again, seeing cmderr=3. In the end, it will know that (a) it must halt to do abstract accesses and (b) that this register doesn't exist. If the implementation prioritized them in the opposite order then the debugger would still eventually come to the same conclusion.
I wanted to raise this concern but it's relatively minor and I don't think that this should derail the ratification process.
The text was updated successfully, but these errors were encountered: