Nother little one, this time in varobj.c

[Andrew Cagney]

> Keith Seitz wrote:
> 
>> 
>> On Tue, 9 Apr 2002, Jim Ingham wrote:
>> 
> 
>> > BTW, I am not sure why it is necessary to call reinit_frame_cache here.
>> > Keith, do you remember why this was necessary?  It is inefficient,
>> > especially if you are evaluating a bunch of variables that are fairly
>> > high up on the stack.  But since I don't remember why this was done, I
>> > am reluctant to just change it outright...
> 
>> 
>> I haven't a clue, actually. When I originally wrote varobj for Insight, it
>> did not allow varobjs to change frames dynamically, as it does now.
>> Presumably, this was all added at the same time. (Or I've forgotten all
>> about it...)
>> 
> 
> 
> The frames code was already there when I converted it to gdbtk-varobj.c,
> so it was added in between.  It seemed to work though.

Just FYI,

GDB is trying to move away from the global selected_frame switching 
technique.  The theory is that there is ``always'' a frame so that the 
selected frame parameter is made explicit to the code that uses it.  As 
the conversion goes through, there is going to be an intermediate mess.

As for reinit_frame_cache() who knows.  One reason for trying to push a 
``keep it simple stupid'' flush-on-write approach (just flush everything 
if the target changes) is that, as with the above, no one is sure what 
the existing strategy is.

enjoy,
Andrew