[PATCH] D75168: [sanitizer][RISCV] Implement SignalContext::GetWriteFlag for RISC-V

[Alex Bradbury via Phabricator via llvm-commits]

asb added a comment.

In D75168#1909097 <https://reviews.llvm.org/D75168#1909097>, @luismarques wrote:

> In D75168#1907941 <https://reviews.llvm.org/D75168#1907941>, @asb wrote:
>
> > There are some cases where you need to perform more checking in order to be future proof for possible new standard extensions. Specifically, review the RVC Instruction Set Listings in the RISC-V spec and check for where an encoding is marked as "RES" (reserved). e.g. C.LWSP is valid only if rd!=0, and the version with rd=0 is a reserved encoding. Similar with C.LDSP. I think it's just those two.
>
>
> I'm not sure that's something we want to do. Those are reserved for HINT instructions. The spec says:
>
> > This HINT encoding has been chosen so that simple implementations can ignore HINTs alto-
> >  gether, and instead execute a HINT as a regular computational instruction that happens not to
> >  mutate the architectural state.
>
> If the core truly supports those HINTs then it shouldn't trap. If we are trapping presumably it's because the core is just executing the HINT as a plain load/store. That would typically be a NOP, but the address must be invalid and so we are trapping. In that case we are correctly identifying it as a `READ` or `WRITE`.


Compressed instruction encodings marked 'RES' are not the same as those marked 'HINT', so I think my reasoning for checking for those reserved encodings remains valid. From the spec:

> Several instructions are only valid for certain operands; when invalid, they are marked either RES to indicate that the opcode is reserved for future standard extensions; NSE to indicate that the opcode is reserved for custom extensions; or HINT to indicate that the opcode is reserved for microarchitectural hints




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75168/new/

https://reviews.llvm.org/D75168