This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Nother little one, this time in varobj.c
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Fernando Nasser <fnasser at redhat dot com>,Keith Seitz <keiths at redhat dot com>, Jim Ingham <jingham at apple dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 10 Apr 2002 10:33:24 -0400
- Subject: Re: Nother little one, this time in varobj.c
- References: <Pine.GSO.4.33.0204092335270.2411-100000@cse.cygnus.com> <3CB43CB7.F7BBB223@redhat.com>
> 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