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>