Re: [Qemu-devel] Add native debugger

[Rick Hodgin]

Andreas,

Thank you.  I guess I'll go back to Bochs.  Things are simpler there. :-)

I do appreciate your help.

Thanks and best regards,
Rick C. Hodgin

--- On Sun, 11/27/11, Andreas Färber <address@hidden> wrote:

> From: Andreas Färber <address@hidden>
> Subject: Re: [Qemu-devel] Add native debugger
> To: "Rick Hodgin" <address@hidden>
> Cc: "Blue Swirl" <address@hidden>, address@hidden
> Date: Sunday, November 27, 2011, 9:28 AM
> Am 27.11.2011 15:12, schrieb Rick
> Hodgin:
> > --- 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.
> 
> Still I don't think a new *debugger* is what you want for
> what you
> describe. Take a look at target-i386/translate.c, that's
> where QEMU
> decodes the opcodes. Note that this is code generation
> time, not
> runtime, so that you either need to emit a call to a helper
> of yours
> whenever that int 3 opcode is found and do your processing
> from that
> helper or to realize your processing with just TCG
> instructions.
> 
> For displaying assembly instructions you could also surely
> reuse
> existing tools from within your implementation, possibly
> i386-dis.c.
> 
> HTH,
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg,
> Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB
> 16746 AG Nürnberg
> 
>