Re: [Qemu-devel] Add native debugger

[Rick Hodgin]

Blue,



--- On Sun, 11/27/11, Blue Swirl <address@hidden> wrote:
> On Sun, Nov 27, 2011 at 04:10, Rick
> Hodgin <address@hidden>
> wrote:
> > For i386, I'm considering writing a native debugger
> for QEMU that is not GDB. It would allow a separate/new
> windowed interface which would show disassembly, registers,
> stack, local variables, memory windows, etc., allowing the
> user to single-step through code and trap opcodes like INT
> 1, INT 3, INT 4, etc.  It would be invoked with something
> like "qemu -debugger" from the command line, and would have
> a UI similar to Microsoft's Debugger in Visual Studio when
> no PDB is available, but would show a similar type of
> disassembly form.
> 
> QEMU and the debugger should be kept separate. You should
> use the GDB interface to implement the debugger, that way
> you can also test it against known good configuration. For
> example, try to find out how GDB performs single stepping
> (set remote debug 1).

I appreciate this advice. I'm looking for a native implementation within QEMU 
that is always available, always on, always active (when enabled). In this way, 
whenever INT 3 opcodes are found, the debugger can intercept and leap into 
existence, and without all of the gdb protocol overhead and parsing.

> > I was looking at the QEMU code and I can't find an
> > obvious place where it seems to iterate through each CPU
> > instruction, which is where I had in mind to add a hook.
> >
> > Can someone get me pointed in the right direction?
> > Where will I look for something like this:
> >
> > for (;;)
> > {
> >  execute_next_instruction();
> > }
> 
> QEMU does not work like that at all, it uses TCG, KVM or
> Xen to execute the code and none of those use that kind
> of single instruction loop either.

There must be some place where it fetches opcodes for what's coming up next to 
execute.  For my implementation I'm using a single i386 core, and that's all 
I'm concerned about for now.  I'd like to intercept that part of the loop where 
cs:e/ip is used to retrieve the next opcode, so that I can check every 
instruction to see if the native debugger window has received GUI stuff asking 
for a pause, if there are breakpoints, etc.

I'd like help on how to do this, and not advice on using gdb instead.  There 
are some particular reasons I want to use my own native debugger in this way.  
I just need pointed in the right direction to get started.  That's for 
assistance toward this end. :-)

Thanks and best regards,
Rick C. Hodgin