48 lines
2.4 KiB
Plaintext
48 lines
2.4 KiB
Plaintext
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
|