Both HWBPs and EBREAKs populate mtval

[aswaterman]

This is a normative change, but it is backwards compatible, since writing 0 to mtval remains a legal option.

Resolves #600

[nick-knight]

Is the technical term "breakpoint exception" defined earlier?

[gfavor]

Effectively yes - see Table 3.7 in the Priv spec.

…

[nick-knight]

To clarify, the "breakpoint exceptions" are precisely the three mcause == 3 exceptions:

• Instruction address breakpoint
• Environment break
• Load/Store/AMO address breakpoint

in Table 3.7?

[gfavor]

Yes, all the (three) line items with Exception Code = 3.

[gfavor]

Which raises the potential need for a clarification? It's clear that "Environment break" results from an EBREAK instruction, whereas the address breakpoints (resulting from Trigger Module address triggers firing) need to be understood to be "hardware" breakpoints.

[nick-knight]

Okay. This matches my understanding from a (long ago) reading of Chapter 10 of the RISC-V Reader (pp.101-102):

Breakpoint exceptions arise from executing an ebreak instruction, or when an address or datum matches a debug trigger

I guess I never read this part of the Priv. spec. that carefully to notice the difference. Good spot, Andrew.

[aswaterman]

@allenjbaum gets credit for spotting the inconsistency; I merely proposed the wording of the fix!

[aswaterman]

I'm going to merge this since it doesn't seem controversial, but please reopen #600 if further discussion is warranted.