From: Richard Henderson <richard.hender...@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>
