How to block local variables?

How to block local variables?

[Leon Pollak]

Hello,
    I use Insight with remote "serial" target and therefore the data
"extraction" from it is not very fast.
    I noticed that if the routine I am stepping through has rather big
amount of local vars the "step time" is long.
    Is my hypothesis, that on each step all local variables are renewed
is correct?
    And if yes, how can this be blocked?
    Many thanks for possible help.
leonp@plris.com

Re: How to block local variables?

[James Ingham]

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

 > Hello,
 >     I use Insight with remote "serial" target and therefore the data
 > "extraction" from it is not very fast.
 >     I noticed that if the routine I am stepping through has rather big
 > amount of local vars the "step time" is long.
 >     Is my hypothesis, that on each step all local variables are renewed
 > is correct?
 >     And if yes, how can this be blocked?
 >     Many thanks for possible help.
 > leonp@plris.com
 > 
 > 
 > 

Re: How to block local variables?

[Leon Pollak]

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.



Leon Pollak
leonp@plris.com

Re: How to block local variables?

[Keith Seitz]

Leon Pollak wrote:
> 
> 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.

Um, I don't think so. GDB does, however, update the register cache every
time the inferior's state changes. To see how much data is flying around
over a remote connection, use the remotedebug or remotelog variables:
these will show you exactly what's going on at the protocol level
(provided your target uses gdb's remote protocol).

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

Re: How to block local variables?

[Fernando Nasser]

Leon Pollak wrote:
> 
> 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.
> 

Hi Leon,

Could you elaborate on what evidence led you to believe that the variables are still being updated? 
You did close the window, did not minimize it, right?

The Local Variables window creates something that we call variable objects.  However, those are
destroyed when they are not visible.  Even if they were not, the "check for updated values" routine
must be called for any action to be taken, and that would require the window to be open and
processing events.  The mechanism is not active, but passive.

You may be seeing some other activity.  There are loads of things that go on when gdb starts/stops
the target program.  If you give us some more hints we may be able to guess what is it that you are
seeing.

Regards,
Fernando

-- 
Fernando Nasser
Cygnus Solutions (a Red Hat company)    E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: How to block local variables?

[James Ingham]

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