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: Thiemo Seufer
Subject: Re: [Qemu-devel] Problems with MIPS full system emulation and breakpoints
Date: Tue, 11 Sep 2007 11:03:06 +0100
User-agent: Mutt/1.5.16 (2007-06-11)

Daniel Jacobowitz wrote:
> 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.

It fixes the FPU emulation problem.

> 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.

Works fine for me.


Thiemo




reply via email to

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