From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HexVz-00057P-Ab for qemu-devel@nongnu.org; Fri, 20 Apr 2007 14:07:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HexVy-00055h-3f for qemu-devel@nongnu.org; Fri, 20 Apr 2007 14:07:22 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HexVx-00055W-M3 for qemu-devel@nongnu.org; Fri, 20 Apr 2007 14:07:21 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HexQr-00046h-Lp for qemu-devel@nongnu.org; Fri, 20 Apr 2007 14:02:05 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l3KI22U9017016 for ; Fri, 20 Apr 2007 11:02:02 -0700 (PDT) Message-ID: <4629005B.7030301@windriver.com> Date: Fri, 20 Apr 2007 13:03:07 -0500 From: Jason Wessel MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040109020005090607080502" Subject: [Qemu-devel] Problems with MIPS full system emulation and breakpoints Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------040109020005090607080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It seems there is an issue with the translation block flushing when writing to the code regions in the MIPS full system emulation. Using a 2.6 kernel which is basically running in single user mode, I use an extremely simple program: main () { int i; for (i = 0; i < 10; i++) { printf("doing %i\n",i); } } / # gdb simple_program (gdb) break main Breakpoint 1 at 0x400670: file simple_program.c, line 3. (gdb) run Starting program: /simple_program Breakpoint 1, main () at simple_program.c:3 3 for (i = 0; i < 10; i++) { (gdb) n 4 printf("doing %i\n",i); (gdb) n doing 0 3 for (i = 0; i < 10; i++) { (gdb) n doing 1 Program received signal SIGTRAP, Trace/breakpoint trap. main () at simple_program.c:3 3 for (i = 0; i < 10; i++) { At this point the program is trashed on the second time through the loop because the translated block with the breakpoint op code was executed instead of being flushed and translated with the correct original instruction. All the single stepping and jumping over the function calls is done by writing a breakpoint op code in and later restoring the original instruction. In the kernel access_process_vm() was used via ptrace to correctly read and write the breakpoints, and I have verified these writes are occurring. To illustrate the problem further, I attached a patch that makes this problem go away. Of course this is not the right fix, because it only deals with the breakpoint opcode and does not isolate the translated block that had the instruction that changed. In theory you should be able to modify any part of the instruction code from another process with ptrace. Are there any suggestions as to how to fix this the right way? The real hardware of course does not exhibit this issue. Thanks, Jason. --------------040109020005090607080502 Content-Type: text/x-patch; name="malta_tb_flush_HACK.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="malta_tb_flush_HACK.patch" Index: qemu/target-mips/helper.c =================================================================== --- qemu.orig/target-mips/helper.c +++ qemu/target-mips/helper.c @@ -360,6 +360,7 @@ void do_interrupt (CPUState *env) goto set_EPC; case EXCP_BREAK: cause = 9; + tb_flush(env); goto set_EPC; case EXCP_RI: cause = 10; --------------040109020005090607080502--