Date: Sun, 26 Sep 93 03:18:19 EDT
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Message-Id: <9309260718.AA13966@tantalus.nrl.navy.mil>
To: bob@amscons.amscons.com
Cc: linux-activists@Niksula.hut.fi
In-Reply-To: Bob Amstadt's message of Sat, 25 Sep 1993 23:36:32 +0300
    <m0oggMt-000CrhC@amscons.amscons.com>
X-Mn-Key: WABI


>I may just be dreaming, but I'm beginning to like the idea of a built
>in debugger.

	So do I.  I like it so much that I wrote one.  It turns out that the
disassembly code in gdb is pretty much localized to one source file, and this
was easy to splice into a simple program.  In addition, there are 2 variables
that you set if you are disassembling 16 bit code, so it makes it all the
better.

	Anyway, there is a parser that understands a limited set of gdb
commands (very limited, but the 'x' command is pretty functional as long as you
stick to numeric rather than symbolic addresses).  The parser understands $pc
and $sp for your convenience, and you can do things like "x/10i $pc" and "info
regs" to see what is going on.  In principle you can do "x/x", "x/s", "x/d",
"x/w", "x/b", "x/i" and "x/c".  I implemented an "info stack" command that
simply dumps a number of bytes from the stack onto the screen, but it currently
makes no attempt to actually interpret the stack frames.

	This will probably not work on non-linux systems, and I have no idea
how much work it will be to fix it.  To start with we need some simple macros
to determine (based upon a segment selector) whether we are in a 16 bit or a 32
bit segment, but this should be pretty easy to fix.  I shamelessly ripped off a
bunch of files from gdb, and I obviously picked the ones for linux.  For other
systems you may need to make adjustments to these files somehow.  It is too
late in the evening to worry about this now.

	It will probably be easy to modify the parser to allow you to change
memory locations and/or register values and then continue execution.  Also,
some of the hooks for using readline with the parser are in place, but it does
not work reliably for some reason, so I left it out for now.  Adding gnu
readline really would bloat the package a lot.  Instead I could use Rich Salz's
editlib (the canonical test case for the DLL tools), which has a command line
history feature that could be an acceptable substitute - this is much smaller
than gnu readline, but I am not sure what features are present.

-Eric