Re: [RFC] Alternate approach to keeping convenience variables

Daniel Jacobowitz
2006-01-24T19:24:44Z

On Tue, Jan 24, 2006 at 11:16:38AM -0800, Jim Blandy wrote:
> On 1/24/06, Daniel Jacobowitz <drow@false.org> wrote:
> > > Right, but there's no way to test for that in the scripting language.
> > > Your 'init-if-undefined' command has to be a primitive, implemented in
> > > C. My argument was that having the variables always be present is
> > > more convenient for user-defined commands.
> >
> > Andrew's point is that such a primitive was recently committed :-)
>
> If you want your user-defined command to print a helpful error mesage,
> you can't use that in an 'if'. If we had some operator like
> $defined($foo), then that'd be different.

At this point we've gotten pretty far afield from the original
question. How does defined($foo) help relative to having the variables
always present?

To refresh, here's what an unpatched GDB without a symbol file shows:

(gdb) show convenience
$trace_frame = -1
$tpnum = 0

With a symbol file:

(gdb) show convenience
No debugger convenience variables now defined.
Convenience variables have names starting with "$";
use "set" as in "set $foo = 5" to define them.

With a tracepoint:

(gdb) show convenience
$tpnum = 1

And, presumably, $trace_frame is set when you're actually using
tracepoints (which I can't test).

I think that the "without symbol file" output should be replaced by the
"with symbol file" output. I don't think it likely that there are
any existing scripts that this would break. If there were, they could
add "init-if-undefined $tpnum = 0" and "init-if-undefined $trace_frame
= -1", and be back where they started from.

For those not using tracepoints, or huge .gdbinit scripts which know
about tracepoints, it's nice to hide the tracepoint variables. Can you
think of any example that would break? Since GDB is normally used
with a symbol file, it seems unlikely.

--
Daniel Jacobowitz
CodeSourcery