"Access Memory" abstract commands - semantics of write operations

[JanMatCodasip]

If Access Memory abstract commands (defined by the debug spec) are supported on a CHERI hart, what should be the effect of the write operation on the capability tag?

Should the semantics of the store instructions from the CHERI spec apply to this case? Quoted below:

All store instructions, except for the RVY SY, always write zero to the capability tag or capability tags associated with the memory locations that are written to. Therefore, misaligned stores may clear up to two associated capability tag bits.

[tariqkurd-repo]

I expect the tag to be set to zero.
Would you ever want to send a valid capability via an abtract command?
The point of drootc is to be able to get hold of a root-cap in debug mode. which other capabilities can be derived from.

[JanMatCodasip]

Tariq Kurd (@tariqkurd-repo) Thank you for your reply. I have the same opinion but wanted to confirm this and also write down to the spec.

My proposal is under: #1069

[resistor]

The hypothetical use case for writing valid capabilities via abstract command is for register save/restore to host. OpenOCD, for example, assumes that it can save device GPRs to the host, executing multiple abstract commands (note that the dscratch registers are not preserved across ACs), and then restoring the GPRs from the host.

Absent that ability (and I agree that writing valid capabilities via AC is undesirable otherwise), we need to consider alternative ways to allow the debugger to save and restore GPRs, such as providing additional scratch registers which are guaranteed to be preserved across ACs.

[JanMatCodasip]

Hi Owen Anderson (@resistor), thank you for your reply. This thread is about memory abstract commands and there is a second one about register abstract commands. Let's please move the discussion there to keep the conversations easier to follow for newcomers.