On Thu, 16 Jan 2025 at 11:48, Ilya Leoshkevich <i...@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 > > Some of these may be wrong due to unfamiliarity with the respective > architectures, sorry - but this illustrates the idea. Ah, yes, thanks for the clear explanation. The "throw away the TB" design didn't consider that (or vice-versa). thanks -- PMM
