RE: [PATCH] target/ppc: fix single-step exception regression

[Luis Fernando Fujita Pires]

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>