execute1: Fix trace interrupt on sc instruction
authorPaul Mackerras <paulus@ozlabs.org>
Tue, 9 Aug 2022 02:30:48 +0000 (12:30 +1000)
committerPaul Mackerras <paulus@ozlabs.org>
Tue, 9 Aug 2022 02:30:48 +0000 (12:30 +1000)
commit939c7e39ddbd0f9ffce5da65729d375334bd46c0
treebdc8f352ab26118a0fb167dbf9cda8dd81ae4bc6
parent2641e6d5cd91a4c84e13f16cd5586f6431dc93a0
execute1: Fix trace interrupt on sc instruction

This fixes a bug which causes a trace interrupt to store the wrong
value in SRR0 in the case where the instruction that has just
completed is followed by a sc (system call) instruction.  What happens
is that first the traced instruction sets ex1.trace_next.  Then, when
the sc instruction following it comes in, the execute1_actions process
sets v.e.last_nia to next_nia because it is an sc instruction, even
though it is not going to be executed -- we are going to take the
trace interrupt instead.  Then when the trace interrupt is taken, we
incorrectly set SRR0 to the incremented address (the address of the
instruction following the sc).

To fix this, we have execute1_actions set a new flag if the current
instruction is sc, and only set v.e.last_nia to next_nia if we
actually execute the sc (in the "if go = '1'" case).

Fixes: 813e2317bf1f ("execute1: Restructure to separate out execution of side effects", 2022-06-18)
Reported-by: Anton Blanchard <anton@linux.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
execute1.vhdl