breakpoint exception and mret

77 views
Skip to first unread message

JAYANTH R

unread,
May 2, 2024, 5:08:14 AMMay 2
to RISC-V ISA Dev
1) if I use the ebreak statement in asm code , will it set a breakpoint exception ?
2) is this breakpoint exception a trap ?
3) if I use mret/xret statement after ebreak , does it mean now that returned from the trap and the trap can delegated ? How do I find if mret is executed or not ?  

JAYANTH R

unread,
May 2, 2024, 5:35:32 AMMay 2
to RISC-V ISA Dev, JAYANTH R
any sample to implement breakpoint exception and then return machine mode using mret 

Daniel Petrisko

unread,
May 2, 2024, 5:58:57 AMMay 2
to JAYANTH R, RISC-V ISA Dev
1) if I use the ebreak statement in asm code , will it set a breakpoint exception ?

Yes (with non-germane caveats)

2) is this breakpoint exception a trap ?

Yes

3) if I use mret/xret statement after ebreak , does it mean now that returned from the trap and the trap can delegated ? How do I find if mret is executed or not ?  

yes xret returns from the to yEPC at privilege mode xPP. This sequence is described in the privileged spec

An example is here in the riscv test suite:

Best,
-Dan

On May 2, 2024, at 2:35 AM, JAYANTH R <jayant...@gmail.com> wrote:

any sample to implement breakpoint exception and then return machine mode using mret 
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5da5c415-684b-47ca-8ef7-68fc782eedf1n%40groups.riscv.org.

Allen Baum

unread,
May 14, 2024, 5:03:59 PMMay 14
to Daniel Petrisko, JAYANTH R, RISC-V ISA Dev
Your questions are a bit ambiguous. Yes, eBreak will cause a trap with the cause set to eBreak, and ePC to the address of the break instruction.
But delegation happens at trap entry; it changes where the trap handler is located, and the mode in which the trap handler is executed.
IIf MEDELEG[3] is clear, eBreak will enter a trap handler at the address in MTVEC in Mmode (where 3 corresponds to exception cause 3, eBreak).
IF MEDELEG[3] is set,   eBreak will enter a trap handler at the address in STVEC in Smode.
If, in the Mmode trap handler, you execute MRET, you will return to the eBreak instruction, effectively going into an infinite loop. 
Hint: update xEPC before using the xRET instruction.


If, in the Mmode handler, (so you didn't delegate) you want to manually delegate, (as if the MDELEG bit had been set ),
then you need to go through a whole sequence of updating CSRs so that MRET will return to where properly delegating would have taken you, 
with all the Smode  trap state set correctly 
Or, you can set the MEDELEG bit and just return, which will retrap (but not quite an inifinite loop because it retraps to a different address)
to the delegated address as if it had been delegated from the state (but all eBREAK ops will delegate from then on, and that cannot be undone without trapping to Mmode).).

Reply all
Reply to author
Forward
0 new messages