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 <afaer...@suse.de> wrote: > From: Andreas Färber <afaer...@suse.de> > Subject: Re: [Qemu-devel] Add native debugger > To: "Rick Hodgin" <foxmuldrs...@yahoo.com> > Cc: "Blue Swirl" <blauwir...@gmail.com>, qemu-devel@nongnu.org > Date: Sunday, November 27, 2011, 9:28 AM > Am 27.11.2011 15:12, schrieb Rick > Hodgin: > > --- 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. > > 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 > >
