[Top][All Lists]
[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