|
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
|
|
|
Mark Hill
Hi Anne,
Nice to hear from you
J
Yes you will need to increment the epc to continue. The handler needs to read the byte at the address mepc, if the bottom two bits
are 0’b11 then it’s a 4 byte instruction.
Mark
toggle quoted message
Show quoted text
From: tech-privileged@... [mailto:tech-privileged@...]
On Behalf Of Anne MERLANDE via lists.riscv.org
Sent: 09 February 2021 14:49
To: tech-privileged@...
Subject: [RISC-V] [tech-privileged] epc increment in case of C.EBREAK
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
|
|
|
Note that if the EBREAK comes from a lower privilege mode, the address put into mepc is the virtual (not physical) instruction address of the EBREAK instruction. Hence M-mode will need to use the MPRV mechanism to read the instruction byte as if the load instruction was executing in that lower privilege mode. Similarly, the MXR bit may need to be used if reading from an execute-only memory location. So, some minor fun and games for the M-mode handler.
Greg
Hi Anne,
Nice to hear from you
J
Yes you will need to increment the epc to continue. The handler needs to read the byte at the address mepc, if the bottom two bits
are 0’b11 then it’s a 4 byte instruction.
Mark
From: tech-privileged@... [mailto:tech-privileged@...]
On Behalf Of Anne MERLANDE via lists.riscv.org
Sent: 09 February 2021 14:49
To: tech-privileged@...
Subject: [RISC-V] [tech-privileged] epc increment in case of C.EBREAK
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
|
|
|
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.
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
|
|
|
Mark Hill
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
toggle quoted message
Show quoted text
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.
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
|
|
|
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.
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 10:05 PM Andrew Waterman < andrew@...> 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.
I mis-misremembered.
To clarify the mtval behavior for [C.]EBREAK instructions: mtval is permitted to either be zeroed or written with the faulting address (i.e. the PC) on a software breakpoint. This is a backwards-compatible change made a few months ago that will become part of priv v1.12.
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.
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
|
|
|
