binutils-gdb/gdb/README.GDBTK

282 lines
10 KiB
Plaintext
Raw Normal View History

README.GDBTK for gdb-4.14 release
Created April 11, 1995 by Stu Grossman
This file describes how to build, install, use and hack on GDBtk, a TK based
GUI for GDB, the GNU debugger.
Introduction
============
GDBtk is a version of GDB that uses Tcl/Tk to implement a graphical user inter-
face. It is a fully integrated GUI, not a seperate front-end program. The
interface consists of several seperate X windows, which use standard elements
like buttons, scrollbars, entry boxes and such to create a fairly easy to use
interface. Each window has a distinct content and purpose, and can be enabled
or disabled individually. The windows contain things like the current source
file, a disassembly of the current function, text commands (for things that
aren't accessible via a button), etc...
Building and installing
=======================
Building GDBtk is very straightforward. The main difference is that you will
need to use the `--enable-gdbtk' option when you run configure in the top level
directory. You will also need to install Tcl version 7.3 (or 7.4), and Tk 3.6.
[We haven't ported to Tk 4.0 yet.]
You will also need to have X11 (R4/R5/R6) installed (this is a prerequisite to
installing Tk).
[See the GDB README file for more details on configure options and such.]
For example:
host> cd gdbtk
host> ./configure --enable-gdbtk
host> make
host> make install
Using GDBtk
===========
Just run it like you would a normal GDB (in fact, it's actually called `gdb').
If everything goes well, you should have several windows pop up. To get going,
hit the start button, and go exploring.
If you want to use GDB in command line mode, just use the -nw option. Or, you
can undefine the DISPLAY environment variable.
In the current version, you can have up to 6 windows active at once. They are:
1) Command
2) Source
3) Disassembly
4) Register
5) Auto Command
6) Expression
Most windows have a similar layout consisting of a menubar, display area,
scrollbar, status box and window-specific buttons.
The menubar contains the following items:
File - General file control. Also has window close and quit buttons.
Options - Window specific options.
Window - A menu of other windows that can be popped up or created.
Help - Mostly unimplemented.
The status box indicates things like the current file and function, or the
current PC and function depending upon the window.
Command window:
This can be used to type commands at GDB (useful for when there isn't a
button for what you want to do).
Source window:
This contains the current source file. The margin displays line
numbers, and has an indicator for lines that actually contain code (and
therefore can have breakpoints as well). When a breakpoint is set at
that line, the indicator is replaced with a `B'.
The buttons are:
Start - Put a breakpoint at main, and then run.
Stop - Stop the program (only active when program is running).
Step, Next, Cont[inue], Finish, Up, Down - Same as the corresponding
GDB command. (Finish runs the current subroutine until it's done.)
Bottom - Does a `frame 0' to put you at the innermost call frame.
There are also accelerators for various buttons (just type the letter
without any control/meta/alt/shift in the text frame):
s - Step
n - Next
c - Continue
f - Finish
u - Up
d - Down
The mouse can also be used to set and clear breakpoints when clicked
in the margin (on a breakpoint indicator).
Disassembly window:
This displays a disassembly of the current function. It's buttons are
similar to those of the source window, except that it uses Stepi and
Nexti to run one instruction at a time instead of one statement at a
time. The accelerators and mouse actions are also similar.
Additionally, there is an option to enable mixed source and assembly.
Register window:
This displays the registers. It may have to be resized to properly
display all the registers. The displayed registers can be selected
via the Options|Config menu item.
Auto Command window:
Using this window, you can specify a command to be executed frequently.
The output will be automatically updated. Options|Accumulate-output
can be used to avoid clearing the window each time so that you can
accumulate a history.
Expressions:
The expression window can be used to just calculate an expression, or
to watch the value of an expression (ala the `display' command), using
the Update button. The expression window will also pop up
automatically when an expression is double-clicked in the source window.
Customizing GDBtk
=================
There are three primary ways to customize GDBtk. One is to modifiy the appropriate
X resources. The other is to hack a ~/.gdbtkinit file. The last is to change
gdbtk.tcl, which defines the most basic interface elements.
X resources give you control over things like the choice of fonts, color
schemes and some geometry info.
For more serious customizations, you will probably need to hack your ~/.gdbtkinit
or gdbtk.tcl files.
X Resources
===========
The class name for GDBtk is `Gdb', and it's appname is `gdb'. The top-
level windows have instance names of `src', 'asm', 'reg', and 'cmd'. The main
display area in each has the class `Text'. So, to change the font in all the
main display areas, something like the following will do:
Gdb*Text*font: fixed
To change the font in only the source window:
Gdb*src*Text*font: fixed
To find out the names of the widgets do the following (in the command window):
tk info comm .*
To get the list of resources (and their classes) for a given widget, do some-
thing like:
tk .asm.text config
This will return a list of lists, where each sublist looks something like this:
{-height height Height 24 25}
The first item is the name of the config option used when creating the widget.
The second item is the instance name of this resource, the third is the class
name. The fourth item is the default value, and the last item is the current
value.
To get info about a single resource, add the config option name to the end of
the previous command. Ie:
tk .asm.text config -font
will return just the info about the font.
To find out the class of a window, just do:
tk winfo class .asm.text
Note that some things may be explicitly overridden by gdbtk.tcl. In
particular, the `tk colormodel . monochrome' command should probably be
disabled if you want to use color.
Hacking ~/.gdbtkinit and gdbtk.tcl
==================================
~/.gdbtkinit is sourced at the end of gdbtk.tcl. Currently there is no good
doc on this. See gdbtk.tcl for see what you can change.
The GUI is primarily implemented by Tcl/Tk code which lives in gdbtk.tcl and a
C file called gdbtk.c. The Tcl/Tk code determines the look and feel, the
layout, and the functions associated with all of the interface elements. The C
code is mostly just glue between GDB internals and Tclland. In essence, all of
the policy is implemented in Tcl/Tk, and is easily changed without recompiling.
To make more serious changes to the interface, such as adding a new window or
changing the framework, you will have to hack gdbtk.tcl. This file is
installed in $(libdir) (probably /usr/local/lib/). But, you will probably want
to hack on your own private copy before putting it up for the rest of the
users. GDB actually searches three places for gdbtk.tcl. First, it looks in
the GDBTK_FILENAME environment variable. Second, it looks for ./gdbtk.tcl.
And third, it looks for $(libdir)/gdbtk.tcl.
Internally, GDBtk is basically GDB, linked with Tcl/Tk, and some glue code that
interfaces GDB internals to Tclland. This means that GDBtk operates as a
single program, not a front-end to GDB. All GDB commands, and a great deal of
the target program state are accessible to the Tcl programmer. In addition,
there are many callbacks from GDB to notify Tclland of important events.
Here is a brief rundown of the GDB<=>Tcl interfaces:
Tcl->GDB calls:
gdb_cmd - sends a text command to gdb. Returns the result
gdb_loc - takes PC, and returns a list consisting of a short file name,
the function name, a long file name, the line number and the
PC (in case you didn't supply it).
gdb_sourcelines - Takes a filename, and returns a list of lines that
contain code.
gdb_listfiles - Returns a list of all of the source files.
gdb_stop - Stops the target process.
gdb_regnames - Returns a list of all of the register names.
gdb_fetch_registers - Returns the contents of the specified registers.
gdb_changed_register_list - Returns a list of registers that have
changed since the last call.
gdb_disassemble - Takes a function or PC. Returns the text of a dis-
assembly of the entire function.
gdb_eval - Takes an expression. Returns it's value.
gdb_get_breakpoint_list - Does the obvious.
gdb_get_breakpoint_info - Takes a breakpoint number. Returns a list of
info about that breakpoint.
GDB->Tcl callbacks:
gdb_tcl_fputs - Sends output into Tcl for the command window.
gdb_tcl_query - Pops up a query window.
gdbtk_tcl_breakpoint - Notifies Tcl of changes to a breakpoint.
gdbtk_tcl_idle - Notifies Tcl that debugged process is now idle.
gdbtk_tcl_busy - Notifies Tcl that debugged process is now running.
For details, see the usage in gdbtk.tcl, or the definitions in gdbtk.c.
Additionally, there is a new GDB command `tk', which can be used to poke at
Tk/Tcl from the command window.
Problems
========
During building, you may run into problems with finding Tcl, Tk or X11. Look
in gdb/Makefile, and fix TCL_CFLAGS, TCL, TK_CFLAGS, TK, and ENABLE_CLIBS as
appropriate.
If you one of the following messages when you run gdb:
Tcl_Init failed: can't find init.tcl; perhaps you need to
install Tcl or set your TCL_LIBRARY environment variable?
or
Tk_Init failed: can't find tk.tcl; perhaps you need to
install Tk or set your TK_LIBRARY environment variable?
then you haven't installed Tcl or TK properly. Fix the appropriate environment
variable to point at the {tcl tk}/library directory, and restart gdb.
If you get the following:
/usr/local/lib/gdbtk.tcl:1: couldn't read file "/usr/local/lib/gdbtk.tcl": No such file or directory
Stack trace:
can't unset "auto_index": no such variable
while executing
"unset auto_index"
then GDBtk wasn't installed properly. You can set the GDBTK_FILENAME
environment variable to point at the gdbtk.tcl in your source directory. Note
that the stack trace displayed here is not valid. If you actually get an error
in gdbtk.tcl, the stack trace is useful to pinpoint the location.