EBREAK and mtval #600
Comments
|
(FWIW, Spike and Rocket both set mtval to the PC when executing an EBREAK instruction, which if "hardware breakpoint" is defined to mean "not EBREAK" is a violation of the spec.) |
|
I take "hardware breakpoint" to be a breakpoint trigger in the Trigger
Module (defined by the Debug Spec as an "execute address trigger"), and
take "software breakpoint" to be an EBREAK. It would seem desirable for
both causes for entering a debug handler to behave the same, i.e. both put
the PC in mtval.
Also note that the Debug spec refers to "debug exceptions", and to
"hardware" and "software" breakpoints (which match my preceding statement)
as causes of debug exceptions. Whereas the Unpriv spec talks in more
general terms in saying that an EBREAK "returns control to a debugging
environment".
Hence ...
On Mon, Oct 12, 2020 at 4:46 PM Andrew Waterman ***@***.***> wrote:
- Is this the right definition? Should EBREAK also be allowed to set
mtval to the PC? (Note that making this change is backwards compatible,
since zeroing mtval remains a legal implementation, at least at the ISA
level.)
I would say Yes.
- Do we need to clarify somewhere that EBREAK is not a hardware
breakpoint?
That would be a useful clarifying non-normative sentence to have. This
would also then tie in with the Debug spec more clearly.
Greg
|
|
It turns out this sentence (and the corresponding one in the supervisor chapter) are the only places we were using the term "hardware breakpoint", so the clarification isn't needed if the sentence is reworded to say "breakpoint exception" (which of course includes both cases). |
This is a normative change, but it is backwards compatible, since writing 0 to mtval remains a legal option. Resolves #600
|
That sounds like a good resolution.
|
|
That's odd - the Riscof folks just said that the newest version of spike does not populate mtval. |
|
Oh, and the SAIL model doesn't populate it either. |
|
It is redundant with epc--but only if the cause wasn't a hardware watchpoint (a.k.a. ld/st breakpoint). So I think there's utility in populating it, if only to help a tiny bit with low-level debugging. It is basically HW-cost neutral (especially since writing 0 is still a legal option). |
|
@allenjbaum the latest version of spike is indeed storing a 0. |
|
So (pedantic hat on) is it the case that both SW breakpoints and HW
breakpoints based on instruction address (as opposed to ld/st address, at
least) must always do the same thing?
That is, is it legal to have one return 0 in MTVAL and the other to return
the PC?
…On Tue, Oct 13, 2020 at 2:33 AM Neel Gala ***@***.***> wrote:
@allenjbaum <https://github.com/allenjbaum> the latest version of spike
is indeed storing a 0.
Fix is to change the arguments to function in c_ebreak.h
<https://github.com/riscv/riscv-isa-sim/blob/master/riscv/insns/c_ebreak.h>
and ebreak.h
<https://github.com/riscv/riscv-isa-sim/blob/master/riscv/insns/ebreak.h>
to be pc instead of 0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#600 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJR4H2TF3CXJZPNRL5DSKQNHHANCNFSM4SNVMOKA>
.
|
|
I think whether the debug triggers are required to do something in particular w.r.t. mtval is a matter for the debug spec, right? |
This is a normative change, but it is backwards compatible, since writing 0 to mtval remains a legal option. Resolves #600
The spec remarks that mtval is written with the virtual address on hardware breakpoints. It is mum about the EBREAK instruction, which currently means mtval should be set to 0.
There are two questions:
The text was updated successfully, but these errors were encountered: