Re: [debug] Digest for debug@groups.riscv.org - 2 updates in 1 topic

[justin james]

http://samsungteleportinfinite.com/

Justin James

On Thu, Aug 16, 2018 at 8:19 AM <de...@groups.riscv.org> wrote:

de...@groups.riscv.org

Google Groups

Topic digest
View all topics

• Single stepping onto an ebreak with DCSR[ebreak*] set - 2 Updates

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

apr...@gmail.com: Aug 15 01:21PM -0700 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 "I*f 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 <t...@sifive.com>: Aug 15 02:09PM -0700 > 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 > 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

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to debug+un...@groups.riscv.org.