Faulting virtual address is written to mtval after ebreak instruction.

[JaewonHur]

While cross-checking Spike and Rocket chip, there was a mismatch between them.
When ebreak instruction is triggered, Spike writes the faulting virtual address to mtval register. However Rocket chip doesn't.

I also issued it to the Rocket chip git, and the answer was as follow.
chipsalliance/rocket-chip#2348
could you check this behavior?

Spike commit number: 157143b

Here's the test I used.
You can make binary executable file by typing make
and I ran spike -l test

test.zip

[aswaterman]

@JaewonHur, hello again, and thanks for your bug report. As I mentioned on the other ticket, the spec says that mtval should be written with 0 in this case, since a software ebreak is not one of the conditions in the following passage:

"When a hardware breakpoint is triggered, or an address-misaligned, access-fault, or page fault exception occurs on an instruction fetch, load, or store, mtval is written with the faulting virtual address. On an illegal instruction trap, [...]. For other traps, mtval is set to zero, but a future standard may redefine mtval's setting for other traps."

I'm going to fix this now, but I want to bring it to @timsifive's attention on the off chance this bug fix has knock-on effects on the debug side of things.