⟦97417a4e5⟧

TextFile

This is the first Beta test of xgdb. I have still not had time to
prepare adequate documentation for this package and can only apologise
for the poor quality of what follows (the fact that I'm half asleep
as I write this also does not help). I felt that it would be better to
kick it out the door with poor documentation (well, ok, NO documentation)
that to sit on it for another week. I expect that all the beta testers
are clever enough to figure most of it out (when in doubt, push it!).

I am, of course, at your disposal for any questions, complaints, flames,
compliments or letter bombs that you may care to send.


Several things remain unfinished:

1. The autoexec view.

  When this is implemented, it will allow you to create a number of
  regions (both "large" and "small") in the autoexec window that
  display the output of some arbitrary command. I.E. Each region will
  have a command associated with it that will be executed each time
  the debugger stops. The output of this command will be displayed
  in the region itself. (It will also be possible to enable and disable
  certain regions to prevent their commands from being executed).

2. The debugged process output window.

  I/O from the process being debugged (not gdb itself) currently
  goes into the void, unless you specifically re-assign it with the
  "tty" button to some file or tty. This should be automagically redirected
  to a slave xterm window, but I don't know how to do this (help?).
  I'd really appreciate some help on this one. I am unable to find *any*
  code that uses a slave xterm except saber, and I don't have the source for
  that.

3. The Info widget.

  This needs a lot more work before it will be usable. When finished, it
  will allow you to browse xgdb's TexInfo document (forthcoming) along with
  the documentation for gdb itself.

4. Support for emacs.

  There wasn't time to get xgdb to talk to emacsclient for optional
  file/line tracking, but this should be done soon. This is sort of near
  the bottom of the list, so if anyone wants to hack it in I'll cheerfully
  accept diffs.


There are probably more than a few bugs, but that's what Beta tests are
for. All feedback is welcomed.


-----
1. Overview.

xgdb currently consists of 7 individual "views":

The "main" view.
The "assembly" view.
The "auto exec" view.
The "breakpoint" view.
The "source" view.
The "stack" view.
The "status" view.

The main view consists of 5 panes. The top pane contains all buttons
for communicating with the debugger. Below it is a label showing which
version of xgdb is running. Clicking the left button on this label
will allow you to pop up any of the various subviews. The buttons
below this label are for controlling xgdb itself (currently only
quitting or restarting the debugger is supported). The next region
is called the "input area" and is used for supplying arguments (if
any) to any of the debugger commands. I.E. If you wanted to search
for the word "main", you would type (or paste) "main" in the input
area and hit the "search>" button.

The input area can be cleared by hitting ^C (or using the appropriate
ascii text widget editing commands).

Finally, we have the debugger's output area. This uses Adam deBoor's TTY
widget and behaves much like an interactive session to gdb. You can
communcate with gdb directly here, though it is suggested that you
use the buttons if at all possible (it's easier to track changes coming
back). Some things, like searches, will in fact not do what you expect
unless you use the buttons.

Debugger output may be redirected to another window by clicking on
the "gdb" label above the output area. This is useful if you wish
to make some lengthy query of the debugger and keep it around for
a while. Multiple redirections are possible.


Each of the other views are fairly simple. They each a contain close box
for "closing" the view, though this can also be done by typing "Q" while
in the window along with any view specific labels/buttons necessary.

Clicking at a source line/address in the source or assembly view will
cause a breakpoint to be set there. Typing "s" in either view will cause
the debugger to step one source line or address, respectivly. (this can,
of course, also be done with the step and stepi buttons).

Clicking on a stack view item will cause the debugger's "current frame"
to move there. You can also type "u" or "d" while in the stack view
to move up or down.

The status view contains any miscellaneous information about xgdb's current
state.

The breakpoint view contains all breakpoints. When a breakpoint is hit,
it is "selected" and shown in reverse video. It remains selected/shown
until another breakpoint is hit, or the breakpoint is deleted.
Breakpoints may be selected for deletion/disabling by clicking on their
entries in the view.



2. Structure of xgdb.

xgdb was designed to be as debugger independent as possible, though the
proof-of-concept for this remains to be done (I.E. another debugger
port). The only files that currently know about gdb are:

gdb.c:	Is responsibly for generating all gdb commands and creating gdb
   specific buttons in the top pane of the "main" view.

gdb-parse.c: Is responsible for parsing all gdb output and setting
   xgdb state and/or causing views to display information.

gdb-regexps: Contains all the special regular expression parsing data
   for the "generic" parser in regparse.c.

There are actually a few routines left like "assemblyDisplayFunction()"
that know a little bit about gdb, but this will change. There hasn't
been sufficient time to clean up the few routines left that don't play
by the rules.


3. Do I need to do anything to gdb?

Yes. There are some minor patches to 3.1.2 in xgdb.gdb.PAT that should be
applied. Negotiations are under way with Randy Smith to get all this
taken care of in 3.2, so the patches should only be necessary for a short
time.


4. Where do I complain?

Mail can be sent to jkh@violet.berkeley.edu, hubbard@decwrl.dec.com or
directly to me in Germany after July 9th to: jkh@meepmeep.pcs.com.
Either way, it will get to me. 

Issues raised before July 9th will naturally be quite a bit easier
to deal with, as I'll still have internet access, but I'll be happy
to hear them either way.



					Jordan Hubbard
					DEC Western Research Labs (DECWRL)
					July 5th, 1989.
					hubbard@decwrl.dec.com
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦97417a4e5⟧ TextFile

Derivation

TextFile
