Mail Archives: djgpp/1998/03/29/10:18:34
(I cc: this to the news group, since it might be of interest to others.)
On Sun, 29 Mar 1998, James W Sager Iii wrote:
> Sometimes I use many different watch variables, and
> due to the fact that I have TONS of pointers, they can get very long.
> Since the watch editor is very weak, I'd like to use a more powerful editor
> to make my wtach variables. Also I'd like to save them to use later if I
> have unexpected debugging to do.
RHIDE's built-in debugger is based on GDB, the GNU Debugger (also
available as a stand-alone debugger in v2gnu/gdbNNNb.zip, where NNN is the
last version). I *know* that GDB supports such a feature. You can write
a script of commands which you need to execute once in every session, and
put them on a file. If that file is called `gdb.ini', GDB will
automatically load it when it starts. If you only want the file loaded
when you need it, you can call it otherwise and load it whenever you
like.
Since RHIDE is based on GBD, I'd guess it supports this facility as well.
(Robert, can you confirm this please?)
GDB also has powerful features designed specifically for these scripts,
which enable you to examine complex data structures and bit-mapped
variables with a simple command. You can even write your own commands in
that scripting language, save them on a file and then use them. For
example, the following excerpt from the gdb.ini file which comes with GNU
Emacs defines a command "xint" which prints the value of an Emacs integer
type:
set $valmask = ((long)1 << gdb_valbits) - 1
set $nonvalbits = gdb_emacs_intbits - gdb_valbits
define xint
print (($ & $valmask) << $nonvalbits) >> $nonvalbits
end
document xint
Print $, assuming it is an Emacs Lisp integer. This gets
the sign right.
end
To read more about these facilities, go to the chapter called "Canned
Sequences of Commands" in the GDB manual.
- Raw text -