On Thu, 16 Jan 2025 at 11:48, Ilya Leoshkevich <iii@linux.ibm.com> wrote:
On Thu, 2025-01-16 at 11:06 +0000, Peter Maydell wrote:
The original reported problem here seems to me like it's a
problem with whatever target's frontend code this is.
This is a single instruction TB, so either:
* the generated code for it completes the insn without
raising an exception (no problem)
* the generated code for it should raise an exception
without having modified the CPU state (so there would
be nothing to do for restore_state_to_opc)
It sounds like the target is generating code which does
something like:
* do part of the instruction, including updating some of
the CPU state
* then decide it needs to raise an exception, and rely on
the restore_state_to_opc handling to undo the state updates
it did previously
The assumption of the "throwaway single insn TB" is that
you don't do that (i.e. that restore_state_to_opc is only
there for the benefit of multi-insn TBs).
The problem is not a partial state update in an instruction, but rather
that on some targets restore_state_to_opc is more than just a
"restore" - it is also "prepare for handling an exception", i.e.:
- arm: exception.syndrome
- hppa: unwind_breg, psw_n
- mips: btarget
- openrisc: ppc
- riscv: excp_uw2
- s390x: int_pgm_ilen