Abstract Command : Access Registe GPR Mandatory ?

[Paul George]

I was drawing up an implementation of a debug spec compliant debug module for integration with an out of order core and was looking for something that was minimally invasive in a structural sense.

The debug spec mandates the presence of the Access Register : Abstract Command 

at :(spec 14.0-Draft , Chapter 3 , page 7 ). 

..
2. Allow any individual hart to be halted and resumed. (Required) 
3. Provide status on which harts are halted. (Required) 
4. Provide abstract read and write access to a halted hart’s GPRs. (Required)
..

and at :(spec 14.0-Draft , 3.7.11 , page 13). 

"Debug Modules must implement this command and must support read and write access to all GPRs when the selected hart is halted. Debug Modules may optionally support accessing other registers, or accessing registers when the hart is running. Each individual register (aside from GPRs) may be supported differently across read, write, and halt status."

Working in the space of my structural constraints , i.e. no abstract commands. I find that it the spec can comfortably accommodate debugging any riscv target implementing a simple combination of ::

1] Memory Access Through System Bus Access.

2] GPR/FPR/CSR by using the program buffer / quick access.

while respecting the present specifications of the Program Buffer  and  System bus access .

Are there any fundamental limitations to the above I may be missing ?

This configuration would need a few updates to riscv-openocd but like its present elegant implementation would not need any explicit run time target specific config as all features are still discoverable.

Can the Hard Requirement for Abstract GPR Access be softened or be redefined to accommodate such a possible valid alternative implementation?