From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18531 invoked by alias); 20 Dec 2006 18:39:27 -0000 Received: (qmail 18518 invoked by uid 22791); 20 Dec 2006 18:39:24 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Dec 2006 18:39:20 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Gx6LP-0006qo-JZ for gdb-patches@sources.redhat.com; Wed, 20 Dec 2006 21:39:15 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1Gx6GU-0006QG-A6; Wed, 20 Dec 2006 21:34:06 +0300 From: Vladimir Prus Subject: Re: variable objects and registers To: Nick Roberts , gdb-patches@sources.redhat.com Date: Wed, 20 Dec 2006 18:39:00 -0000 References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <17800.24415.300779.516967@kahikatea.snap.net.nz> User-Agent: KNode/0.10.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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/msg00267.txt.bz2 Nick Roberts wrote: > > ? 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 don't think this particular interface decision is important, but I don't follow your general principle. It does not matter if Apple ports their code to FSF, or we do it -- if differences are introduces for no good reason, it makes it harder to merge changes for everyone, and that's bad. > > > I slightly prefer > > > > -var-list --locals > > -var-list-create --locals? -var-create-list --locals? I've settled on -var-list. I don't think 'create' clarifies much, and this is not user command, and '-var-list-children' also creates variable objects without having 'create' in the name. > > 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. By "updates" you mean '-var-update' or regetting new list of locals and creating new vars? > In Emacs, I update after every GDB command using "info > locals" which is quicker Quicker than what? -var-update? Is this a measurable difference? If so, we should fix it. > but not as good. We need to find a way to detect > when the frame changes FWIW, KDevelop uses "info frame" > 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. I think that we need more higher-level notification -- namely "new locals appeared" and either: - "varobj now refers to different object" - or have a command that creates varobjs for all variables in a function. That way, we won't need to guess how varobjs should be changes when frame id changes. > > > >... > > > +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. That function creates and returns variable object. Calling it 'create_var_in_frame' would imply that it creates some 'var', and that would not be accurate. > Likewise with existing functions: > > varobj_update_one --> var_update > print_varobj --> print_var This one, too, prints variable object. > so that they are in the file you would expect to find them. I'm not sure. I don't know why a name of a function should map to the name of the file in the way you indicate. - Volodya