qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Problems with MIPS full system emulation and breakpoint


From: Daniel Jacobowitz
Subject: Re: [Qemu-devel] Problems with MIPS full system emulation and breakpoints
Date: Mon, 10 Sep 2007 11:34:48 -0400
User-agent: Mutt/1.5.15 (2007-04-09)

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: qemu-mips-breakpoints.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]