From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5977 invoked by alias); 19 Dec 2006 21:58:20 -0000 Received: (qmail 5963 invoked by uid 22791); 19 Dec 2006 21:58:19 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Dec 2006 21:58:12 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-55.snap.net.nz [202.124.125.55]) by viper.snap.net.nz (Postfix) with ESMTP id 3DC553D98AB; Wed, 20 Dec 2006 10:59:41 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 15C78BE456; Wed, 20 Dec 2006 10:53:37 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17800.24415.300779.516967@kahikatea.snap.net.nz> Date: Tue, 19 Dec 2006 21:58:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: variable objects and registers In-Reply-To: References: <17782.41205.881283.845357@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.0.91.19 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00255.txt.bz2 > ? Or maybe we should not mix easy "create one varobj from expression" > command with "create a bunch of varobj" command and add the following: > > -var-create-and-list --registers ... > -var-create-and-list --locals ... > -var-create-and-list --whatever-else ... A separate command does indeed seem best. > or just "-var-list"? On the other hand, on Apple branch the varobjs for > locals are created using > > -stack-list-locals --make-varobjs Most of the functionality seems to come from varobj.c so, unless Apple contribute this code to the FSF repository, I see no need to follow their approach. > I slightly prefer > > -var-list --locals -var-list-create --locals? -var-create-list --locals? Insight creates variable objects for display of locals. The delay is quite apparent when there are more than a couple of them, but it only updates when the frame changes. In Emacs, I update after every GDB command using "info locals" which is quicker but not as good. We need to find a way to detect when the frame changes and report it e.g * NOTIFY-ASYNC-OUTPUT contains supplementary information that the client should handle (e.g., a new breakpoint information). All notify output is prefixed by `='. =frame-changed I started looking at this in the thread http://sourceware.org/ml/gdb/2006-06/msg00162.html but didn't make good progress. > >... > > +static struct varobj * > > +create_varobj_in_frame (char *name, char *expression, char *frame) > > +{ > > + CORE_ADDR frameaddr = 0; > > + struct cleanup *cleanup; > > + enum varobj_type var_type; > > + > > + if (strcmp (frame, "*") == 0) > > + var_type = USE_CURRENT_FRAME; > > + else if (strcmp (frame, "@") == 0) > > + var_type = USE_SELECTED_FRAME; > > + else > > + { > > + var_type = USE_SPECIFIED_FRAME; > > + frameaddr = string_to_core_addr (frame); > > + } > > + > > + if (varobjdebug) > > + fprintf_unfiltered (gdb_stdlog, > > + "Name=\"%s\", Frame=\"%s\" (0x%s), Expression=\"%s\"\n", > > + name, frame, paddr (frameaddr), expression); > > + > > + return varobj_create (name, expression, frameaddr, var_type); > > +} > > + > > > > I think the function above should go in varobj.c > > Then, the varobj.c would have to expose magic "@" and "*" values in its > interface. I think it's better to keep this closer to parsing code and keep > varobj.c separated. Yes. OK, in that case I would call the function create_var_in_frame. Likewise with existing functions: varobj_update_one --> var_update print_varobj --> print_var so that they are in the file you would expect to find them. -- Nick http://www.inet.net.nz/~nickrob