From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14911 invoked by alias); 11 May 2008 14:58:34 -0000 Received: (qmail 14902 invoked by uid 22791); 11 May 2008 14:58:34 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 11 May 2008 14:58:14 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JvD08-0001u5-7q for gdb-patches@sources.redhat.com; Sun, 11 May 2008 14:58:12 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 May 2008 14:58:12 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 May 2008 14:58:12 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: RE: [PATCH:MI] Return a subset of a variable object's children Date: Sun, 11 May 2008 17:45:00 -0000 Message-ID: References: <6D19CA8D71C89C43A057926FE0D4ADAA042910B6@ecamlmw720.eamcs.ericsson.se> <200805011954.31277.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BD10@ecamlmw720.eamcs.ericsson.se> <200805012239.59601.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BD13@ecamlmw720.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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: 2008-05/txt/msg00356.txt.bz2 Marc Khouzam wrote: >> If a variable is deleted from variables tree (because you left the scope >> where that variable is defined), then you should delete variable object. >> There's no reliable way to detect that exactly same variable is in scope >> again and must be shown, so no reuse is possible. > > We chose a more passive approach. The frontend relies entirely on GDB to > know if a varObj has gone out-of-scope. Since GDB reports this > only if the varObj is given the var-update command, we don't get to know > it very often, because we only use the var-update command for varObj we want > to know the value of. > I believe an example is in order :-) > > Say you have local variable bar in method foo(). > We create a varObj for bar. Once we return from foo(), there is no longer > a local variable bar, so we don't send a -var-update for it, which in turn > means we don't realize that it is out-of-scope and we don't delete it. > > What this implies in the end is that we only delete a varObj if our cache > is full. The only exception to this rule is when the expression of a > variable object is re-used which will trigger a var-update, which will > show that the old varObj is out-of-scope (so we create a new one.) > (if after returning from foo(), there is another local variable bar) That does not sound like an ideal approach, because given that GDB knows for sure which variable objects are in scope, and which are not, you are using some heuristics to to guess that, and it will never be 100% ideal. Having said that, while GDB knows everything, MI interfaces are somewhat lacking as far as local variables are concerned. I plan to design command(s) that allow to easily and reliably track local variables, and will post those. >> > > There are natural scalability bounds in the UI -- if there are no >> > > arrays involved, and you try to show 1000 items (backed by 1000 variable objects), >> > > the UI is already useless. GDB is not the problem here. >> > >> > Right, but for us the 1000 varObj are not meant to all be displayed at once >> > but are a caching system. >> >> I'm still not sure what you mean -- you mean that a variable object is not shown >> in any widget, but only is stored in the cache? What is the key of the cache? > > Ah yes, the key of the cache. That gave me a big headache :-) > It is a object containing: the expression for the varObj, the thread it is part of, > and the frame level. > If the same expression (variable name) is used in the same thread at the same frame > level, then we first think it is the same varObj and we use -var-update; we then > get an out-of-scope and we delete the old varObj and create a new one. I see. I hope this approach won't be necessary soon (though only if you're willing to conditionalize the logic in gdb version). - Volodya