From: Daniel Jacobowitz <drow@false.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Problems with MIPS full system emulation and breakpoints
Date: Mon, 10 Sep 2007 11:34:48 -0400 [thread overview]
Message-ID: <20070910153448.GA2747@caradoc.them.org> (raw)
In-Reply-To: <20070420182209.GA18563@caradoc.them.org>
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
On Fri, Apr 20, 2007 at 02:22:09PM -0400, Daniel Jacobowitz wrote:
> I have an idea. When I was talking to Paul about breakpoints
> recently, I noticed something very strange in the ARM port: it
> continues to disassemble the instruction under a breakpoint after
> generating the debug op. This is a waste of CPU and memory, so I
> tried taking it out - but he told me that if I did that, things would
> go wrong because the size of the tb would be too small. We'd try to
> flush the tb at the breakpoint location, but it wouldn't seem to cover
> there.
>
> MIPS doesn't do that extra disassembly because it has a goto instead
> of a break from the nested loop. What happens if you add an extra
> +1 to the translation block size if there's a breakpoint, in
> target-mips/translate.c?
It won't help because that problem related to "hardware" breakpoints
through QEMU's gdb stub.
The attached patch fixes that, and Jason's issue, and probably the
FPU emulation issue also. The real problem was "tb->size = 0" in the
search_pc case. Alpha, ARM, m68k, mips, ppc, sh4, and sparc all
did this. But it can't be right - the tb passed when searching for a
pc is in the cache, and clearing its size prevents it from being
flushed properly.
I got a couple of strange oopses after this, and one unidentified
lockup. I don't think they are related, though.
--
Daniel Jacobowitz
CodeSourcery
[-- Attachment #2: qemu-mips-breakpoints.patch --]
[-- Type: text/x-diff, Size: 3027 bytes --]
--- target-alpha/translate.c (revision 181278)
+++ target-alpha/translate.c (local)
@@ -2047,7 +2047,6 @@ int gen_intermediate_code_internal (CPUS
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
- tb->size = 0;
} else {
tb->size = ctx.pc - pc_start;
}
--- target-arm/translate.c (revision 181278)
+++ target-arm/translate.c (local)
@@ -3656,7 +3656,6 @@ static inline int gen_intermediate_code_
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
- tb->size = 0;
} else {
tb->size = dc->pc - pc_start;
}
--- target-m68k/translate.c (revision 181278)
+++ target-m68k/translate.c (local)
@@ -3260,7 +3260,6 @@ gen_intermediate_code_internal(CPUState
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
- tb->size = 0;
} else {
tb->size = dc->pc - pc_start;
}
--- target-mips/translate.c (revision 181278)
+++ target-mips/translate.c (local)
@@ -5882,10 +5882,6 @@ static void decode_opc (CPUState *env, D
generate_exception(ctx, EXCP_SYSCALL);
break;
case OPC_BREAK:
- /* XXX: Hack to work around wrong handling of self-modifying code. */
- ctx->pc += 4;
- save_cpu_state(ctx, 1);
- ctx->pc -= 4;
generate_exception(ctx, EXCP_BREAK);
break;
case OPC_SPIM:
@@ -6433,6 +6429,9 @@ gen_intermediate_code_internal (CPUState
save_cpu_state(&ctx, 1);
ctx.bstate = BS_BRANCH;
gen_op_debug();
+ /* Include the breakpoint location or the tb won't
+ * be flushed when it must be. */
+ ctx.pc += 4;
goto done_generating;
}
}
@@ -6493,7 +6492,6 @@ done_generating:
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
- tb->size = 0;
} else {
tb->size = ctx.pc - pc_start;
}
--- target-ppc/translate.c (revision 181278)
+++ target-ppc/translate.c (local)
@@ -5878,7 +5878,6 @@ static inline int gen_intermediate_code_
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
- tb->size = 0;
} else {
tb->size = ctx.nip - pc_start;
}
--- target-sh4/translate.c (revision 181278)
+++ target-sh4/translate.c (local)
@@ -1242,7 +1242,6 @@ gen_intermediate_code_internal(CPUState
ii++;
while (ii <= i)
gen_opc_instr_start[ii++] = 0;
- tb->size = 0;
} else {
tb->size = ctx.pc - pc_start;
}
--- target-sparc/translate.c (revision 181278)
+++ target-sparc/translate.c (local)
@@ -3365,7 +3365,6 @@ static inline int gen_intermediate_code_
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
- tb->size = 0;
#if 0
if (loglevel > 0) {
page_dump(logfile);
next prev parent reply other threads:[~2007-09-10 15:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-20 18:03 [Qemu-devel] Problems with MIPS full system emulation and breakpoints Jason Wessel
2007-04-20 18:22 ` Daniel Jacobowitz
2007-09-10 15:34 ` Daniel Jacobowitz [this message]
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=20070910153448.GA2747@caradoc.them.org \
--to=drow@false.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.