RE: problem with chained if statements?

["Thompson, James C" <James.C.Thompson@USAHQ.UnitedSpaceAlliance.com>]

> From: Stan Shebs [mailto:shebs@cygnus.com]
> No consensus.  The tclites push for tcl of course, but that has
> political problems. Guile would be officially approved of, but no
> actual hacker seems to care enough to contribute actual changes.
> Other ideas surface from time to time, but haven't really gone
> anywhere.  If I was told I could have only one, I would probably
> go with Guile.

I recently added guile scripting support to a simulator project I work on,
and found it fairly easy; we added simple (usually) guile wrappers to each
function that needed to be available as a guile call.  If the gdb command
parser is structured so that each major command -- print, where, next, etc.
-- is bound to a single C function, then adding guile should be
straightforward.  Of course, you probably wouldn't want to completely
supplant the current command parser, but to augment it so that the current
command syntax is still available, with "guile-looking" commands getting
passed off to guile for evaluation.  This is certainly possible.

But I think the real power would be to add hooks into gdb at various places
to which guile scripts can be attached.  Breakpoints, for example: if I
could tell gdb to run a guile script each time a breakpoint is encountered,
then I could do "conditional debugging" by letting the script examine the
inferior program state so that execution pauses only when certain criteria
are met.  Of course, it's possible to accomplish the same thing by building
special debug code into the executable, but that's invasive and
time-consuming -- best case, I have to recompile my program.  The ability to
set up and change these hooks on the fly would be very nice.

--JT

application/ms-tnef