Debug specification missing guidance for E base set (RV32E/RV64E)

[nadime15]

The debug specification does not mention (even though its implied) how abstract commands should handle the E base set (RV32E/RV64E), which reduces the general-purpose register set from 32 to 16 registers (x0-x15 only).

In this case, attempting to access registers x16–x31 (regno 0x1010–0x101f) should result in cmderr = 3 (exception), since these registers do not exist in the hart (arguably, the debugger could drop the 5th bit when accessing one of the upper 16 registers, which we probably don’t want). While this may seem obvious, I believe it would be helpful to state this explicitly in a revised version of the debug specification, because once RV32E or RV64E is enabled, the contents of Table 4 and the set of accessible GPRs change accordingly.

[pdonahue-ventana]

That seems like a useful clarification.

[en-sc]

@nadime15, thank you for raising this issue.

I have a question:

In this case, attempting to access registers x16–x31 (regno 0x1010–0x101f) should result in cmderr = 3 (exception).

Should the abstractcs.cmderr = 3 (exception) be required? Maybe for the case when the x16-x31 registers can not be enabled abstractcs.cmderr = 2 (not supported) can be returned? IMHO, returning not supported gives more information about the target.

[nadime15]

Thats a good point. In theory, a hart could toggle E by disabling I and then checking if E is set to 1. This way, the debugger could simply check misa directly and quickly determine the reason for a failed access.

The "E" bit is read-only. Unless misa is all read-only zero, the "E" bit always reads as the complement of
the "I" bit. If an execution environment supports both RV32E and RV32I, software can select RV32E by
clearing the "I" bit.

As I understand from #1140, abstractcs.cmderr = 2 is determined solely by the command itself. For example, setting aarsize = 4 and trying to access a 32-bit CSR on an RV32 platform would return 2 (not supported). I think this situation, whether we can access 32 or 16 registers, is somewhat similar to floating-point registers: when mstatus.FS is set to 0, accessing an FPR would return 3 (exception).

Please correct me if I have misinterpreted anything.

[en-sc]

IMHO, it seems like it would be more appropriate to discuss the question of the correct abstractcs.cmderr under #1140. Please see my comments there.