README.DEBUGGER - wine - Git at Google

 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
	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