ma_addr test fails if mtval is hardwired to 0

[Luke Wren]

This trap handler in ma_addr.S checks that hardware sets mtval to the load/store address on a load/store alignment exception:

riscv-tests/isa/rv64mi/ma_addr.S

Lines 97 to 108 in fd6e7ed

 mtvec_handler: 
   csrr t0, mcause 
   bne t0, s1, fail 
  
   csrr t0, mbadaddr 
   bne t0, t1, fail 
  
   lb t0, (t0) 
   beqz t0, fail 
  
   csrw mepc, t2 
   mret 

However hardware is not obligated to do anything more than implement the register as hardwired to 0, as per the latest priv spec:

With the following patch, this test passes on my implementation (which hardwires mtval to 0), and is still a useful test, since the actual trap is still exercised:

diff --git a/isa/rv64mi/ma_addr.S b/isa/rv64mi/ma_addr.S
index 721ac6a..f02a1af 100644
--- a/isa/rv64mi/ma_addr.S
+++ b/isa/rv64mi/ma_addr.S
@@ -99,10 +99,12 @@ mtvec_handler:
   bne t0, s1, fail
 
   csrr t0, mbadaddr
+  beqz t0, 1f
   bne t0, t1, fail
 
   lb t0, (t0)
   beqz t0, fail
+1:
 
   csrw mepc, t2
   mret

This probably isn't good enough for upstream, though, because it weakens the test for implementations which attempt to set mtval informatively.

I'm not sure what the best solution is. Maybe it's enough to assert that either all loads/stores set mtval informatively, or all loads/stores set mtval to 0? I'm happy to create any appropriate PRs.

[Andrew Waterman]

Not executing the test on implementations that hardwire mtval to 0 is also an option. But I’d be OK with your proposed patch, too.

[Luke Wren]

Okay, I raised a PR for the simple patch. I'm not looking for trouble.

Edit: I would rather run the test as it still covers logic not covered by other tests.

[Andrew Waterman]

No trouble! Thanks for the suggestion.