Single stepping onto an ebreak with DCSR[ebreak*] set

[apr...@gmail.com]

Hello,

We need some clarification on the settings for DCSR[cause] in the case debugger is  single stepping and hits upon an ebreak, and DCSR[ebreak*] is set to force entry into debug mode.

The DCSR[cause] priorities are listed (high->low) as

1. single step
2. debugger requested
3. ebreak with DCSR[ebreak*] set
4. trigger with action=enter-debug-mode
   

There is a similar case of stepping onto triggers with action=enter-debug-mode, and the specification has an exception noted "If executing or fetching the instruction causes a trigger to fire, Debug Mode is re-entered immediately after that trigger has fired. In that case cause is set to 2 (trigger) instead of 4 (single step)".

Should a similar exception apply to the ebreak case, and the DCSR[cause] indicate ebreak and not single step ?

If the debugger, on a single step, does hit upon a trigger or ebreak  that would take it back to debug mode, it must be able to infer the cause as not single step and take appropriate action (increment DPC etc) prior to resume. Else it would hit the same trigger (if pre-execute) or ebreak again on resume.

Please advise.

Thanks

Ajay

[Tim Newsome]

On Wed, Aug 15, 2018 at 1:21 PM, <apr...@gmail.com> wrote:

Hello,

We need some clarification on the settings for DCSR[cause] in the case debugger is  single stepping and hits upon an ebreak, and DCSR[ebreak*] is set to force entry into debug mode.

The DCSR[cause] priorities are listed (high->low) as

1. single step
2. debugger requested
3. ebreak with DCSR[ebreak*] set
4. trigger with action=enter-debug-mode
   

Those numbers are right, but they're interpreted the other way round. single step has the lowest priority, and triggers have the highest priority. (This was clarified in https://github.com/riscv/riscv-debug-spec/commit/d83039d21a86e46caee5d304a535773a7c4f0b2e. Perhaps your pdf was built earlier than that?)

So if you step onto an ebreak, cause must be set to 1 (ebreak instruction executed).

There is a similar case of stepping onto triggers with action=enter-debug-mode, and the specification has an exception noted "If executing or fetching the instruction causes a trigger to fire, Debug Mode is re-entered immediately after that trigger has fired. In that case cause is set to 2 (trigger) instead of 4 (single step)".

That's not an exception, but it follows the rule above. It does sound like it's documenting an exception, though. :-(

Tim

 

If the debugger, on a single step, does hit upon a trigger or ebreak  that would take it back to debug mode, it must be able to infer the cause as not single step and take appropriate action (increment DPC etc) prior to resume. Else it would hit the same trigger (if pre-execute) or ebreak again on resume.

Please advise.

Thanks

Ajay

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/4de5489f-3e78-4f64-8865-ce179af26391%40groups.riscv.org.