From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSEA1-00039i-9d for qemu-devel@nongnu.org; Thu, 11 Sep 2014 19:52:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSE9s-0004Iz-7Y for qemu-devel@nongnu.org; Thu, 11 Sep 2014 19:52:21 -0400 Received: from mail-qg0-x230.google.com ([2607:f8b0:400d:c04::230]:55822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSE9s-0004Is-3I for qemu-devel@nongnu.org; Thu, 11 Sep 2014 19:52:12 -0400 Received: by mail-qg0-f48.google.com with SMTP id q108so4552375qgd.35 for ; Thu, 11 Sep 2014 16:52:10 -0700 (PDT) Sender: Richard Henderson Message-ID: <541235A6.5050006@twiddle.net> Date: Thu, 11 Sep 2014 16:52:06 -0700 From: Richard Henderson MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] cpu-exec: Don't mask out external interrupts when single-stepping an invalid instruction. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Martin Galvan Cc: QEMU Developers , Anthony Liguori , =?UTF-8?B?QW5kcmVhcyBGw6RyYmU=?= =?UTF-8?B?cg==?= On 09/11/2014 03:13 PM, Peter Maydell wrote: >> The long story: Qemu generates an exception_with_syndrome instruction >> when it realizes the instruction it's trying to translate is invalid. >> That instruction in turn modifies cs->exception_index and calls cpu_loop_exit. >> Normally, the value in cs->exception_index would cause do_interrupt to set >> the PC to point to the corresponding exception handler. >> However, since we're masking out IRQs, the PC will never be set correctly. >> Even worse, since Qemu will have generated an internal exception >> to return control back to the remote Gdb *after* it generated the syndrome one, >> its code will appear after the call to cpu_loop_exit. >> Since the PC won't have changed, we'll try to excecute >> the same translation block as before, thus calling cpu_loop_exit >> again, and so on. This suggests that target-arm (64 or 32-bit?) isn't implementing illegal instruction traping in the way that I'd expect. In particular, I'd expect the invalid exception to be recognized, and then the cpu loop exited, before the single-step exception could overwrite it. E.g. how things work on alpha: $ cat z.s .globl _start _start: nop .long (1 << 26) nop $ alphaev67-linux-as -o z.o z.s $ alphaev67-linux-ld -Ttext-segment 0xfffffc0000100000 -o z z.o $ ./run/bin/qemu-system-alpha -kernel z -S -gdb tcp::12345 & $ alphaev67-linux-gdb ./z Set a breakpoint at _start, continue, swap over to qemu monitor and enable logging of int,op,in_asm. Now single-step a couple of times and we get: IN: 0xfffffc0000100078: nop OP: ld_i32 tmp0,env,$0xfffffffffffffffc movi_i32 tmp1,$0x0 brcond_i32 tmp0,tmp1,ne,$0x0 ---- 0xfffffc0000100078 movi_i64 pc,$0xfffffc000010007c movi_i32 tmp0,$0x10002 movi_i32 tmp1,$0x0 call excp,$0x0,$0,env,tmp0,tmp1 set_label $0x0 exit_tb $0x7f54d4fee013 Notice here that we end the single-step of the insn with a call to excp with 0x10002=EXCP_DEBUG. IN: 0xfffffc000010007c: .long 0x4000000 OP: ld_i32 tmp0,env,$0xfffffffffffffffc movi_i32 tmp1,$0x0 brcond_i32 tmp0,tmp1,ne,$0x0 ---- 0xfffffc000010007c movi_i64 pc,$0xfffffc0000100080 movi_i32 tmp0,$0x7 movi_i32 tmp1,$0x0 call excp,$0x0,$0,env,tmp0,tmp1 set_label $0x0 exit_tb $0x7f54d4fee013 Notice here that we end the single-step of the invalid insn with a call to excp with 7=EXCP_OPCDEC. We never attempt to single-step, because we know that single-step isn't going to be reachable. INT 1: opcdec(0) pc=fffffc0000100080 sp=fffffc0000010000 IN: Pal_OpcDec 0xfffffc0000000380: hw_mfpr t7,0 But gdb does in fact stop at the very next insn, which is of course the PALcode (bios) OPCDEC exception entry point. >> +#define SSTEP_EXCEPTION 0x8 /* Don't mask out exception-related >> IRQs. Set only if >> + * we have to process an exception while single- >> + * stepping (such as when >> single-stepping an invalid >> + * instruction). >> + */ I'm really not sure what you're doing with this, or why you'd need it. Probably target-arm wants fixing in some way, but I don't have time to look into it this evening. r~