Allow for non-word aligned `mtvec` about riscv-arch-test HOT 11 CLOSED

I am also pinging @eroom1966 as we have discussed this a while ago.

from riscv-arch-test.

from riscv-arch-test.

Thanks @allenjbaum for your quick response. I am happy to learn that this problem is being addressed.

from riscv-arch-test.

Well, it will be addressed in the future. It isn't clear to me that it is possible to fix this in v.1, though.

from riscv-arch-test.

Therer are currently 4 tests: I-EBREAK, I-ECALL, I-MISALIGN_JMP and I-MISALIGN_LDST which require access and update of mtvec. While riscof accounts for capturing the platform specifc constraints for mtvec, these tests would also have to be updated along with a linker script changes as well to account for this issue.

from riscv-arch-test.

Is this possible to fix in the current framework to handle arbitrary alignments?
if we only need to modify linker scripts which are already implementation specific, that is doable
If we need to modify tests, that will be implementation specific, and until we can import YAML parameters, we can't have a general test, in which case this should be deferred until we get to v.2.
I don't think we have a way of "deferring" issues; should this get a "fixed in riscof" tag?

from riscv-arch-test.

I think the issue here is that the idiom adopted by Andrew Waterman was used early in the test development, so that the mtvec address is set to be the address of an instruction after the faulting address, in other words (pseudo code)

l1: some_instruction
l2: set mtvec = &l4
l3: faulting_instruction
l4: some_instruction

if the intention is to use a READONLY MTVEC, then a trap handler must be written and located at the fixed MTVEC address, this traphandler could read the EPC and perform a jump to EPC+2 (compressed) or EPC+4 (uncompressed) thus resuming execution at l4

I think it is a test issue, not a framework issue

Thx
Lee

from riscv-arch-test.

from riscv-arch-test.

OK, the tests that have just merged have a standard trap handler that any test can use.
The prolog/setup sets mtvec to a trampoline in the handler that enables saving trap state.
If it is unable to set mtvec to that handler, it instead replaces whatever mtvec points to with the trampoline code.
Only if that fails does it give up & the test fails
A future version may allow implementors to point to a RWX area to place the trampoline table. So:

• An implementation that has a fixed MTVEC that vectors to ROM will always fail
• An implementation that has partially writable MTVEC that is initialized point to ROM when the initialization routine is entered will fail.
  Otherwise, it should work.

from riscv-arch-test.

Has this been retested with the updated RFQ tests?
If not, I suggest you reclone the entire riscv-arch-test (the new name for the old riscv-compliance repo) repo and try again
The new tests should save and overwrite the region that MTVEC points to with a trap vector table, and restore it after the test. Any traps will then get vectored to ther standard trap handler, save trap state, and return past the trap point.

from riscv-arch-test.

Seeing no comments, I believe this has been fixed in the latest version of the tests; that is, the tests that were failing because of mtvec alignment shouldn't be failing now. I am closing this, but please reopen if you see further failures.

from riscv-arch-test.