From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15084 invoked by alias); 24 May 2007 00:05:38 -0000 Received: (qmail 15076 invoked by uid 22791); 24 May 2007 00:05:37 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 May 2007 00:05:35 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hr0ph-0006d9-Ax; Wed, 23 May 2007 17:05:33 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25279-03; Wed, 23 May 2007 17:05:33 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.11.18]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hr0pg-0006d3-Sk; Wed, 23 May 2007 17:05:32 -0700 Message-ID: <4654D6CC.1080604@tensilica.com> Date: Thu, 24 May 2007 00:05:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Jim Blandy CC: Maxim Grigoriev , gdb@sourceware.org, Marc Gauthier , Pete MacLiesh Subject: Re: Understanding GDB frames References: <46521C04.7040405@hq.tensilica.com> <465341B8.9060208@hq.tensilica.com> <46538818.1050601@tensilica.com> <4653A5F3.60503@tensilica.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00146.txt.bz2 Jim Blandy wrote: >Ross Morley writes: > > >>We need to remember, though, that one goal is to minimize the overhead >>for the MI front end of having to re-create varobjs. As we get better >>at detecting a frame change (reduce false positives) we actually increase >>the overhead for the FE because it then (to be correct) needs to recreate >>its varobjs. We should think about solving that problem before we get too >>much better at detecting frame changes. >> >> > >If you don't detect a frame change, then you're displaying garbage, >aren't you? > You're displaying values from a different instance of the function. The (new) frame is still used to find the values, but the varobj is not deleted. Technically it's not the same variable, but from the GUI perspective it's useful to consider it the same, as you described in your previous post. >I'd expect fewer false positives should always be good... > > > Apparently not if it comes at the price of having to recreate varobjs. But it seems we're barking up the wrong tree in worrying about how to detect a variable going out of scope... I just had a long discussion with our eclipse GUI guy, Pete MacLiesh. What the GUI wants is to be able to highlight which variables changed in a function between one breakpoint and the next. It doesn't matter whether we are still in the same instantiation of the function, in a completely different one, or at a different frame level or recursion level. The varobj should be associated strictly with the function, NOT the frame. When its value is updated by -var-update, the frame is used only to find the value (which, according to Pete, might change even as the user clicks up and down the stack of a recursive function). So the answer to Daniel's question: > But what we do need is to clarify our semantics so >> that front ends know what to expect. Should varobjs be destroyed when >> we leave and re-enter a function? If the answer is "maybe", then that >> is confusing enough to deserve some more explanation :-) > > seems to be an unambiguous "no". This begs the question: when should GDB destroy a varobj? Our initial conclusion is that it is probably best to do it only when there are no longer any instances of the function on the stack. Frame ID should not enter into this equation, so gdbarchs are free to implement frame ID the way that is best for them, without unexpected consequences for GUI FEs. Now this requires GDB to walk the entire stack when a function associated with a varobj disappears in order to know that it has disappeared. That is a small overhead compared to the GUI having to re-create possibly dozens of varobjs for many functions, and try to track changes in value independently of GDB. The reason varobjs exist is to avoid that. GDB incurs the overhead only for varobjs, so it does not affect non-MI performance, and performance under MI needs to be considered in light of the entire package with the GUI. I hope this is helpful. Ross