Reporting xTVAL for Trap=true?

[arichardson]

I just had a test case where QEMU and sail reported different trap register numbers for a CHERI exception, but that will only be found if you insert an explicit .4byte 0x343020f3 # (csrrs x1, mtval (0x343), x0 (and we might not always be in m-mode).

It might be a good idea to somehow report the xTVAL value for traps so that we don't have to rely on an explicit CSR read being inserted afterwards.
This would be extremely useful to compare CHERI exception codes and registers now that this is reported in xTVAL.

I believe for trap=true rvfi_dii_rd_wdata is always zero, could we change this to report xTVAL?

[PeterRugg]

Hmm, this is an interesting one and we've thought about similar things in the past.

In general, we could report every piece of changing state - I think there's a framework that does this (Bluespec's TV maybe?).
For example, it could be interesting to report xepcc on trap as well as xtval, xstatus on xret, etc...

I wonder if it's neater to add a new field to the RVFI packet or to merge it into an existing field, as you suggest.

Would a specialised template go some way to solving this? Would your worry about not always being in m-mode be mitigated by always reading utval (when N-mode exists), then stval, then mtval? We could either have a specialised template that tries to provoke traps, or have a Template->Template function that inserts random tval checks. It would be neat to take a template, run it on an implementation, and then add cause/tval checks following any instruction that reported it traps, but we currently have no way of taking RVFI reports into account when generating templates like that.

Of course, differing acceptable implementations of tval will cause issues here - I think it's implementation defined whether illegal instructions report the faulty bits, for example. Sail claims to support both options, but last I checked, the switch didn't work...