From: Jason Wessel <jason.wessel@windriver.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Problems with MIPS full system emulation and breakpoints
Date: Fri, 20 Apr 2007 13:03:07 -0500 [thread overview]
Message-ID: <4629005B.7030301@windriver.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
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.
[-- Attachment #2: malta_tb_flush_HACK.patch --]
[-- Type: text/x-patch, Size: 372 bytes --]
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;
next reply other threads:[~2007-04-20 18:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-20 18:03 Jason Wessel [this message]
2007-04-20 18:22 ` [Qemu-devel] Problems with MIPS full system emulation and breakpoints Daniel Jacobowitz
2007-09-10 15:34 ` Daniel Jacobowitz
2007-09-11 10:03 ` Thiemo Seufer
2007-05-03 20:28 ` [Qemu-devel] Problems with MIPS full system emulation and breakpoints: also for FPU emulation Stefan Weil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4629005B.7030301@windriver.com \
--to=jason.wessel@windriver.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).