From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14890 invoked by alias); 21 Dec 2006 06:43:35 -0000 Received: (qmail 14880 invoked by uid 22791); 21 Dec 2006 06:43:34 -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; Thu, 21 Dec 2006 06:43:29 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1GxHeI-0001Ll-8Y for gdb-patches@sources.redhat.com; Thu, 21 Dec 2006 09:43:27 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GxHeD-0001LO-Hh; Thu, 21 Dec 2006 09:43:21 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: variable objects and registers Date: Thu, 21 Dec 2006 06:43:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <17801.40268.835284.224413@kahikatea.snap.net.nz> In-Reply-To: <17801.40268.835284.224413@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612210942.54734.ghost@cs.msu.su> 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/msg00279.txt.bz2 On Wednesday 20 December 2006 23:30, Nick Roberts wrote: > > > > 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. > > It's easier for Apple to port their changes back than us, and they can always > do this if they wish. If it's easier to put the function in mi-cmd-stack.c I > would call it "-stack-list-locals --make-varobjs", but if it's easier to put it > in mi-cmd-var.c I would call it -var-"something". > > > > > > > > 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, > > Except that it doesn't just list existing variable objects but "creates" new > ones. I fact, I'm not sure what duplicated -var-list --locals should do. Create afresh, or just return already created? > Its _always_ helpful to have a descriptive name. The name itself is not useful without docs, so we need no try too hard. For example, -var-list-create and -var-create-list are also inaccurate, because this command does not create list. It creates variable objects and then lists them. Can we have some reasonable way out of this bikeshed? > > and '-var-list-children' also creates > > variable objects without having 'create' in the name. > > Good analogy. I had to add the fact that it created variable objects for > the children to the manual because the original author had ommitted/forgotten > it. Are you saying we should copy existing bad design? I'm saying this does not matters much. One has to read all the docs anyway. > > > 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? > > The latter. > > > > 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. > > Quicker than regenerating variable objects for all the locals. Yeah, not surprising given that "info locals" is a 'wholesale' operation. > > > but not as good. We need to find a way to detect > > > when the frame changes > > > > FWIW, KDevelop uses "info frame" > > Does this approach know when it's not another invocation of the frame > with the same name? No, but this approach is only the first check. After that the list of all local name is obtained and then addresses of all locals are obtained and compared with previous values. > > 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. > > The latter is "-stack-list-locals --make-varobjs" isn't it? Or are you talking > about variables declared within compound statements? Both. -stack-list-locals --make-varobjs creates variable objects for all variables in a function, including in nested blocks. I think it might be good idea for you and I to go though Apple branch grepping for all "APPLE LOCAL" markers so that we know everything they've added. > > > > 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. > > They're all for variable objects. > > > > 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. > > The distinction I'm making is that var_* functions and variables are for use in > MI and generally live in mi_cmd_var.c while varobj_* ones may be used by > Insight and live in varobj.c I don't think the difference between "var" and "varobj" in function name communicates what you want, and I don't think such a coding guideline makes sense for future. - Volodya