Blue,
--- On Sun, 11/27/11, Blue Swirl <blauwir...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 04:10, Rick
> Hodgin <foxmuldrs...@yahoo.com>
> 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
