target/ppc/translate.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
Commit 6086c75 (target/ppc: Replace POWERPC_EXCP_BRANCH with
DISAS_NORETURN) broke the generation of exceptions when
CPU_SINGLE_STEP or CPU_BRANCH_STEP were set, due to nip always being
reset to the address of the current instruction.
This fix leaves nip untouched when generating the exception.
Signed-off-by: Luis Pires <luis.pires@eldorado.org.br>
Reported-by: Matheus Ferst <matheus.ferst@eldorado.org.br>
---
target/ppc/translate.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index ea200f9637..0dd04696a6 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -4646,8 +4646,7 @@ static void gen_lookup_and_goto_ptr(DisasContext *ctx)
if (sse & GDBSTUB_SINGLE_STEP) {
gen_debug_exception(ctx);
} else if (sse & (CPU_SINGLE_STEP | CPU_BRANCH_STEP)) {
- uint32_t excp = gen_prep_dbgex(ctx);
- gen_exception(ctx, excp);
+ gen_helper_raise_exception(cpu_env, tcg_constant_i32(gen_prep_dbgex(ctx)));
} else {
tcg_gen_exit_tb(NULL, 0);
}
@@ -9128,7 +9127,11 @@ static void ppc_tr_tb_stop(DisasContextBase *dcbase, CPUState *cs)
}
/* else CPU_SINGLE_STEP... */
if (nip <= 0x100 || nip > 0xf00) {
- gen_exception(ctx, gen_prep_dbgex(ctx));
+ if (is_jmp == DISAS_EXIT || is_jmp == DISAS_CHAIN) {
+ /* We have not updated nip yet, so do it now */
+ gen_update_nip(ctx, nip);
+ }
+ gen_helper_raise_exception(cpu_env, tcg_constant_i32(gen_prep_dbgex(ctx)));
return;
}
}
--
2.25.1
On 6/1/21 11:02 AM, Luis Pires wrote: > + if (is_jmp == DISAS_EXIT || is_jmp == DISAS_CHAIN) { > + /* We have not updated nip yet, so do it now */ > + gen_update_nip(ctx, nip); > + } This is incorrect. Both EXIT and CHAIN *have* updated nip, but to something that isn't the next instruction. E.g. return from interrupt. r~
On Tue, Jun 01, 2021 at 01:27:20PM -0700, Richard Henderson wrote: > On 6/1/21 11:02 AM, Luis Pires wrote: > > + if (is_jmp == DISAS_EXIT || is_jmp == DISAS_CHAIN) { > > + /* We have not updated nip yet, so do it now */ > > + gen_update_nip(ctx, nip); > > + } > > This is incorrect. Both EXIT and CHAIN *have* updated nip, but to something > that isn't the next instruction. E.g. return from interrupt. Any theories on what's actually causing the regression, then? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On 6/2/21 1:55 AM, David Gibson wrote: > On Tue, Jun 01, 2021 at 01:27:20PM -0700, Richard Henderson wrote: >> On 6/1/21 11:02 AM, Luis Pires wrote: >>> + if (is_jmp == DISAS_EXIT || is_jmp == DISAS_CHAIN) { >>> + /* We have not updated nip yet, so do it now */ >>> + gen_update_nip(ctx, nip); >>> + } >> >> This is incorrect. Both EXIT and CHAIN *have* updated nip, but to something >> that isn't the next instruction. E.g. return from interrupt. > > Any theories on what's actually causing the regression, then? > I would have thought the first hunk would have some effect. But otherwise this is the first I've heard of the problem. Description? Reproduction instruction? r~
From: Richard Henderson <richard.henderson@linaro.org> > On 6/2/21 1:55 AM, David Gibson wrote: > > On Tue, Jun 01, 2021 at 01:27:20PM -0700, Richard Henderson wrote: > >> On 6/1/21 11:02 AM, Luis Pires wrote: > >>> + if (is_jmp == DISAS_EXIT || is_jmp == DISAS_CHAIN) { > >>> + /* We have not updated nip yet, so do it now */ > >>> + gen_update_nip(ctx, nip); > >>> + } > >> > >> This is incorrect. Both EXIT and CHAIN *have* updated nip, but to > >> something that isn't the next instruction. E.g. return from interrupt. > > > > Any theories on what's actually causing the regression, then? > > > > I would have thought the first hunk would have some effect. But otherwise this > is the first I've heard of the problem. Description? Reproduction instruction? While trying to debug his implementation for one of the new Power ISA 3.1 instructions, Matheus (cc'ed) hit a problem where he'd get a SIGSEGV when using gdb to debug a process inside a guest after commit 6086c75. Steps to reproduce: - Inside a ppc64 VM (running with qemu-system), run gdb to start debugging any program (I tested with /bin/ls, /bin/true and also a simple hello world) - Run the binary from within gdb and you'll get a SIGSEGV Running the same program outside gdb works fine. By looking at 6086c75, I noticed this was happening because when gen_exception() was called from gen_lookup_and_goto_ptr() (due to CPU_SINGLE_STEP | CPU_BRANCH_STEP), nip was being reset to ctx->cia. Before that commit this didn't happen, because ctx->exception != POWERPC_EXCP_NONE. -- Luis Pires Instituto de Pesquisas ELDORADO Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>
© 2016 - 2024 Red Hat, Inc.