From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27909 invoked by alias); 22 May 2007 17:20:24 -0000 Received: (qmail 27864 invoked by uid 22791); 22 May 2007 17:20:19 -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 17:20:14 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqY1o-0004is-RT; Tue, 22 May 2007 10:20:08 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11458-06; Tue, 22 May 2007 10:20:07 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.11.18]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqY1m-0004i5-KN; Tue, 22 May 2007 10:20:06 -0700 Message-ID: <46532642.1030501@tensilica.com> Date: Tue, 22 May 2007 17:20: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: Marc Gauthier CC: Daniel Jacobowitz , Nick Roberts , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh Subject: Re: Understanding GDB frames References: 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/msg00113.txt.bz2 Marc Gauthier wrote: >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. > > 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). > > > I believe the performance implication comes mainly from the MI client having to recreate the MI vars, not so much from the scope breakpoint. If I recall correctly, the scope breakpoint would disappear the first time the var went out of scope, and would not exist subsequent times until the target stops and is resumed again (however it's been a while since I looked at scope breakpoints). Ross