From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20092 invoked by alias); 10 Apr 2002 14:33:28 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20083 invoked from network); 10 Apr 2002 14:33:21 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 10 Apr 2002 14:33:21 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C3AC93F3C; Wed, 10 Apr 2002 10:33:24 -0400 (EDT) Message-ID: <3CB44D34.70409@cygnus.com> Date: Wed, 10 Apr 2002 07:33:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Nasser , Keith Seitz , Jim Ingham Cc: gdb-patches@sources.redhat.com Subject: Re: Nother little one, this time in varobj.c References: <3CB43CB7.F7BBB223@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00398.txt.bz2 > 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