I agree that it is an unusual operation but if it is needed I don’t think you can use mtval as it is defined to be zero on an ebreak/c.ebreak.

 

Mark

 

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: 09 February 2021 21:53
To: anne.merlande@...
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] epc increment in case of C.EBREAK

 

My experience has been that simply skipping over a [C.]EBREAK without first knowing how wide the instruction is not a commonly desired operation.  If the instruction was inserted by a debugger, the debugger already knows how wide of a breakpoint it had inserted at that address, so it knows how far to advance EPC.  If the instruction was inserted by the compiler or programmer to indicate an error condition (which can be determined at runtime by knowing the debugger had not inserted a breakpoint at that address), then it's a fatal trap, and so there's no need to automatically advance EPC.

 

If you really did need to skip over it, you'd need to read the instruction from the mtval CSR or from memory to determine how far to advance EPC.

 

On Tue, Feb 9, 2021 at 6:48 AM Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

Hello
The Privileged spec says that "ECALL and EBREAK cause the receiving privilege mode’s epc register to be set to the address of

the ECALL or EBREAK instruction itself, not the address of the following instruction." (chapter 3.2.1 of Version 1.12-draft).

So I understand that it is up to the handler or the debugger to increment epc (epc+4) so that it returns to the address following the ECALL/EBREAK on mret instruction.
Please could you confirm ?

Then should be the same for the compressed instruction C.EBREAK. But in that case, how the software can know that the epc should only be incremented by 2 ?

thanks for your help
Anne
 

On Wed, Feb 10, 2021 at 2:52 AM Mark Hill <mark.hill@...> wrote:

 

I agree that it is an unusual operation but if it is needed I don’t think you can use mtval as it is defined to be zero on an ebreak/c.ebreak.

Indeed, I misremembered.

 

Mark

 

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: 09 February 2021 21:53
To: anne.merlande@...
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] epc increment in case of C.EBREAK

 

My experience has been that simply skipping over a [C.]EBREAK without first knowing how wide the instruction is not a commonly desired operation.  If the instruction was inserted by a debugger, the debugger already knows how wide of a breakpoint it had inserted at that address, so it knows how far to advance EPC.  If the instruction was inserted by the compiler or programmer to indicate an error condition (which can be determined at runtime by knowing the debugger had not inserted a breakpoint at that address), then it's a fatal trap, and so there's no need to automatically advance EPC.

 

If you really did need to skip over it, you'd need to read the instruction from the mtval CSR or from memory to determine how far to advance EPC.

 

On Tue, Feb 9, 2021 at 6:48 AM Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

Hello
The Privileged spec says that "ECALL and EBREAK cause the receiving privilege mode’s epc register to be set to the address of

the ECALL or EBREAK instruction itself, not the address of the following instruction." (chapter 3.2.1 of Version 1.12-draft).

So I understand that it is up to the handler or the debugger to increment epc (epc+4) so that it returns to the address following the ECALL/EBREAK on mret instruction.
Please could you confirm ?

Then should be the same for the compressed instruction C.EBREAK. But in that case, how the software can know that the epc should only be incremented by 2 ?

thanks for your help
Anne