a few things to fix & gdb

[Roger Gregory <roger>]

There are a few places that our code is very fragile.  The one that
causes the most debugging problems is that printOn often doesn't test
to see that pointers are nonNULL.  This is just a stupid oversight,
and I would correct all of them myself, except that this isn't the right
time.  So after the next merge I'll do that.  Is there anything else
of a similar nature that I should do at the same time?  Checking for 
error returns from system/lib calls comes to mind, but that may be 
mostly deep in the comm and disk stuff and thus worthy of more deep
scrutiny.

The reason that printOn has become more important is that gdb is
almost usable.  I have a dbxinit file that forces in the files I actually
need all the time, so that I don't get hit with 2 minute delays interactively
to read them in.  But since all our routines declare the abstract class,
the gdb or dbx print ruotines just print the abstract class data.  I have
a routine that calls printOn when given an SPTR, but printOn tends to blow up.

Anyway gdb commands that are non obvious
help --  interactive help stuff
bt   -- stack trace
info locals -- gives you the names and data of the local variables
list filename:linenumber -- lists the line in the file, forcing the file in
				as a side effect.  this is thonly way I know
				of to force the files symbols to be read.

print EXP -- prints the expression.  the expression can be a function call
		just remember that you have to use the mangled name

There is an x interface to gdb, but I haven't used it yet.

Run gdb inside of emacs and it gives you a few extra commands bindings (from gdb info in emacs):

Using GDB under GNU Emacs
*************************

A special interface allows you to use GNU Emacs to view (and
edit) the source files for the program you are debugging with
GDB.

To use this interface, use the command `M-x gdb' in Emacs.
Give the executable file you want to debug as an argument.  This
command starts a GDB process as a subprocess of Emacs, with input
and output through a newly created Emacs buffer.

Using this GDB process is just like using GDB normally except for two things:

   * All "terminal" input and output goes through the Emacs buffer.  This
     applies both to GDB commands and their output, and to the input and
     output done by the program you are debugging.

     This is useful because it means that you can copy the text of previous
     commands and input them again; you can even use parts of the output
     in this way.

     All the facilities of Emacs's Shell mode are available for this purpose.

   * GDB displays source code through Emacs.  Each time GDB displays a
     stack frame, Emacs automatically finds the source file for that frame
     and puts an arrow (`=>') at the left margin of the current line.

     Explicit GDB `list' or search commands still produce output as
     usual, but you probably will have no reason to use them.

In the GDB I/O buffer, you can use these special Emacs commands:

`M-s'
     Execute to another source line, like the GDB `step' command.

`M-n'
     Execute to next source line in this function, skipping all function
     calls, like the GDB `next' command.

`M-i'
     Execute one instruction, like the GDB `stepi' command.

`M-u'
     Move up one stack frame (and display that frame's source file in
     Emacs), like the GDB `up' command.

`M-d'
     Move down one stack frame (and display that frame's source file in
     Emacs), like the GDB `down' command.  (This means that you cannot
     delete words in the usual fashion in the GDB buffer; I am guessing you
     won't often want to do that.)

`C-c C-f'
     Execute until exit from the selected stack frame, like the GDB
     `finish' command.

In any source file, the Emacs command `C-x SPC' (`gdb-break')
tells GDB to set a breakpoint on the source line point is on.

The source files displayed in Emacs are in ordinary Emacs buffers
which are visiting the source files in the usual way.  You can edit
the files with these buffers if you wish; but keep in mind that GDB
communicates with Emacs in terms of line numbers.  If you add or
delete lines from the text, the line numbers that GDB knows will cease
to correspond properly to the code.