This is the mail archive of the
insight@sourceware.cygnus.com
mailing list for the Insight project.
Re: How to block local variables?
- To: Leon Pollak <leonp at plris dot com>
- Subject: Re: How to block local variables?
- From: James Ingham <jingham at cygnus dot com>
- Date: Tue, 25 Apr 2000 10:16:51 -0700 (PDT)
- Cc: James Ingham <jingham at cygnus dot com>, insight at sourceware dot cygnus dot com
- References: <390415A2.E05EC472@plris.com><4.3.0.20000425092503.00a94f00@plris.com>
Leon,
> At 11:29 24/04/00 -0700, you wrote:
> >Leon,
> >
> >You are right about how Insight updates local variables. The only
> >way to stop this is to close the local variables window. You can use
> >the Watch window to selectively watch particular variables instead.
> Jim, please, excuse me to return to this, but the window was
> closed and all my experiments show (I know that this may be incorrect, but
> still...) that the window is updated (or the corresponding data is
> retrieved?) even been closed. May it be?
> Once more, excuses.
>
No excuses necessary... If this is true, it is definitely a bug, but
I don't think that it is true. One way to tell is to open the console
and do:
tk info commands var*
all the variables that Insight creates are represented at the Tcl
level by variable access commands, and their names are always of the
form varN or varN.elem where N is an integer, and elem is the name of
a structure element, in the case where varN represents a structure
that is opened. If there are spurious variable objects lying around,
then Insight would try to fetch values for them. But I don't see this
happening on my copy...
Other things that can slow the processing of stepping down over a slow
connection are the stack window (since you have to do a complete stack
crawl at each step to reconstruct this) and the memory window. The
register window is usually not a big deal, since in most ports gdb
fetches all the registers on each stop anyway.
Hope this helps,
Jim