From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6251 invoked by alias); 22 May 2007 18:36:19 -0000 Received: (qmail 6237 invoked by uid 22791); 22 May 2007 18:36:17 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 May 2007 18:36:11 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id E18394B267; Tue, 22 May 2007 13:36:07 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 06B684B262; Tue, 22 May 2007 13:36:05 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HqZDI-00089D-5o; Tue, 22 May 2007 14:36:04 -0400 Date: Tue, 22 May 2007 18:36:00 -0000 From: Daniel Jacobowitz To: Jim Ingham Cc: Marc Gauthier , Ross Morley , Nick Roberts , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh Subject: Re: Understanding GDB frames Message-ID: <20070522183603.GA31229@caradoc.them.org> Mail-Followup-To: Jim Ingham , Marc Gauthier , Ross Morley , Nick Roberts , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh References: <4652AC74.9050100@tensilica.com> <20070522163616.GB25392@caradoc.them.org> <8D85CC15-F5B0-4187-92A9-81C17E631BE0@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D85CC15-F5B0-4187-92A9-81C17E631BE0@apple.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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/msg00116.txt.bz2 On Tue, May 22, 2007 at 11:32:41AM -0700, Jim Ingham wrote: > I don't see what the bad effect of not destroying the varobj if the frame id is > identical is. You might get an errant "value changed" notification. Other than > that, I can't see what you would be gaining. > > If we're going to do some extra work to make sure we mark variables out of > scope when their frames are exited, we should get something real out of it. So > far it seems the benefit is only theoretical. Sure. I'm not seriously proposing we do that extra work, though I did think about it. 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 :-) -- Daniel Jacobowitz CodeSourcery