Re: GDB Console Q

[Keith Seitz <kseitz@firetalk.com>]

Braxton Thomason wrote:
> 
> Actually, that was not quite the problem.  I didnt make myself clear,
> sorry. :)  The _real_ problem is this:
> 
> (gdb) n
> 6: currentStage->mName.mName.dat = 0x20004398 "Execute"
> (gdb)
> 
> and so on is the "normal" behavior, and I get the output on my xterm.
> Thats fine.  The problem arises sometimes when I press run in the GUI, I
> get this behavior from my GDB console:
> 
> (gdd) n
> (gdb) print foo
> (gdb) info breakpoints
> (gdb) info display
> (gdb) display foo
> (gdb) //ARG!!!!! NOThING!!

Ugh. You mean _that_ problem. :-( This can happen in gdbtk because, as
you may or may not know, there is no API for things like GUIs in gdb. As
a result, we had to resort to all sorts of heinous little hacks to get
information out of gdb -- like the values of variables.

The problem you see is a result of something like this. Deep down, gdbtk
is re-routing all calls to *printf_(un)formatted to the console window
(via fput_unfiltered_hook). Some of gdbtk's subsystems (the variable
code, in particular) temporarily reset the fputs_unfiltered_hook so that
it can capture the output of some command. It is supposed to reset it
back to the previous value, but if an error occurs, it is possible that
this reset fails to happen. Your culprit is almost certainly the
variable code.

I believe that Jim threw something in as a safeguard against this not
too far in the past:

1999-08-27  James Ingham  <jingham@leda.cygnus.com>

        * gdbtk-cmds.c [snip]
        (gdb_restore_fputs): New function, restore the gdbtk_fputs hook,
        in case somebody supressed it, and then errored out before they
        got a chance to put it back.

Are you using a relatively recent version?

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com