From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30832 invoked by alias); 22 May 2007 16:10:53 -0000 Received: (qmail 30770 invoked by uid 22791); 22 May 2007 16:10:43 -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; Tue, 22 May 2007 16:10:37 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqWwQ-0006Fb-Tm; Tue, 22 May 2007 09:10:30 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20926-07; Tue, 22 May 2007 09:10:30 -0700 (PDT) Received: from crux.hq.tensilica.com ([192.168.15.35] helo=bell) by mailapp.tensilica.com with smtp (Exim 4.34) id 1HqWwQ-0006Eq-95; Tue, 22 May 2007 09:10:30 -0700 From: "Marc Gauthier" To: "Ross Morley" , "Daniel Jacobowitz" Cc: "Nick Roberts" , "Maxim Grigoriev" , , "Marc Gauthier" , "Pete MacLiesh" Subject: RE: Understanding GDB frames Date: Tue, 22 May 2007 16:10:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4652AC74.9050100@tensilica.com> 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/msg00109.txt.bz2 Ross Morley wrote: > Associating them with the function has problems with recursion. > It seems to > me the ideal is to recreate vars that have gone out of scope (they really > are new vars). Use of a scope breakpoint can better detect that than the > current methods. However, are there implementation or performance issues? As we discussed offline yesterday, this has performance implications on the GUI, which would have to recreate the varobjs every time which is time consuming. One often wants to just set a breakpoint on a function, and go "next - next - next - ..." across all invocations of that function no matter where it's called from, looking at what variables change until one reaches the desired invocation. In this use mode one doesn't care about specific frames, only about the specific function. It's in this particular (common) use model that performance suffers when distinguishing frame scopes. It seems at the MI interface one wants a choice of whether a varobj is associated with: (a) a specific frame (goes away when function returns) (b) a function (c) a function at the same depth (which some implement) How the distinction is made at the GUI level is a separate question. And what to do in the event of recursion when one selected a function-level varobj (b) is also an interesting question -- perhaps it always refers to the topmost instance (or to theseparately selected instance if the currently selected stack depth is to that function). That way, (b) and (c) have less performance impact, and one of them could be the default. And (a) being optional, could be fully supported like watchpoints by setting a breakpoint at the return PC, even though it has a performance hit (especially in the presence of recursion). And perhaps MI docs could even document this ;-) -Marc