Skip to content
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

Priority of various cmderrs #974

Open
pdonahue-ventana opened this issue Feb 23, 2024 · 0 comments
Open

Priority of various cmderrs #974

pdonahue-ventana opened this issue Feb 23, 2024 · 0 comments

Comments

@pdonahue-ventana
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant