I-MISALIGN_JMP-01.S outdated use of `mbadaddr` in trap handler? about riscv-arch-test HOT 7 CLOSED

Agreed that mtval should replace mbadaddr not only here but in all other tests as well.
Will probably raise a pull-request for the same soon. Thanks for the catch.

I think the problem here is how you have interpreted the spec. I would interpret the following
... or an instruction-fetch, load, or store address-misaligned, access, or page-fault exception occurs, mtval is written with the faulting effective address ... as:

instruction-fetch-misaligned, load-address-misaligned, store-address-misaligned,
instruction-fetch-access, load-address-access, store-address-access,
instruction-fetch-pagefault, load-address-pagefault and store-address-pagefault exceptions.

Also there is no exception defined as: instruction-fetch-exception.

In which case a jal/jalr instruction which causes an instruction-fetch-misaligned exception should update mtval with the corresponding instruction-fetch-address.

Also you can find the same behaviour in spike and riscvOPVSim and also quite a few other implementations.

from riscv-arch-test.

Ah, that makes more sense! Thanks for your help!

from riscv-arch-test.

I missed this earlier, but in the paragraph above, the spec states:

"When a trap is taken into M-mode, mtval is either set to zero or written with exception-specific information to assist software in handling the trap. Otherwise, mtval is never written by the implementation, though it may be explicitly written by software. The hardware platform will specify which exceptions must set mtval informatively and which may unconditionally set it to zero."

So the behavior desired by the test isn't actually required by spec. This seems like it would render several tests that use mtval less useful for some targets. Thoughts?

from riscv-arch-test.

I think the ISA-compliance tests should be revised to permit either zero or the expected nonzero value. These tests will still be useful. Implementations will choose to write the expected nonzero value for exceptions that are meant to be resumable, and we still want to test that they produce the right value if they do produce a value.

Platform-compliance tests should be responsible for checking whether mtval is populated with nonzero values for the exceptions that platform cares about (e.g., misaligned ld/st on platforms that emulate those operations; all page-fault exceptions on platforms that use virtual memory).

from riscv-arch-test.

from riscv-arch-test.

Note that the riscof framework will handle this correctly by dreclaring that MTVAL is unimplemented in the DUT YAML configuration file. The reference model will need to allow that kind of configuration (and many, many others) as well.

from riscv-arch-test.

So, I am unclear: is it possible to modify the test so it works for both MTVAL implemented or not?
I thought the current v.1 framework only allows a single assertion, which make it unfixable in v.1

from riscv-arch-test.