From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28617 invoked by alias); 13 Apr 2002 12:42:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28610 invoked from network); 13 Apr 2002 12:42:19 -0000 Received: from unknown (HELO mx04.nexgo.de) (151.189.8.80) by sources.redhat.com with SMTP; 13 Apr 2002 12:42:19 -0000 Received: from einstein.home-of-linux.org (dialin-212-144-185-123.arcor-ip.net [212.144.185.123]) by mx04.nexgo.de (Postfix) with ESMTP id AC00437D17; Sat, 13 Apr 2002 14:42:18 +0200 (CEST) Received: by einstein.home-of-linux.org (Postfix, from userid 1001) id 379C420010; Sat, 13 Apr 2002 14:42:14 +0200 (CEST) To: Momchil Velikov Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Lifetime of local variables References: <86u1qghdp5.fsf@einstein.home-of-linux.org> <20020412194304.B11562@nevyn.them.org> <86bscnesxy.fsf@einstein.home-of-linux.org> <873cxzdcnd.fsf@fadata.bg> From: Martin Baulig Date: Sat, 13 Apr 2002 05:42:00 -0000 In-Reply-To: <873cxzdcnd.fsf@fadata.bg> Message-ID: <86y9frdb2x.fsf@einstein.home-of-linux.org> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00231.txt.bz2 Momchil Velikov writes: > I think ypu are mixing two different concepts here, the language > notion of scope and the compiler/runtime notion of lifetime. I guess > the lifetime is of interest for a debugger. Yes, I was mixing them up a bit. However, my understanding of this was that for a debugger, "scope" means where a variable actually exists (so it should be listed by "info locals" and "print", possibly stating that it's address is unknown) and "lifetime" means where a variable can be accessed, ie. it's actually stored somewhere and it's address/register is known to the debugger. > > I want to use this to debug machine > > generated IL code and the JIT may want to create local variables > > on-the-fly. For variables which have actually been defined by a human > > programmer, listing them and claiming that their value is no longer > > available is IMHO the right thing to do - but I'd like to tell the > > debugger to make a machine-generated variable disappear when it's no > > longer used, otherwise you'd get a large number of automatic variables > > (having numbers, not names, which makes it even more confusing to the > > user) and only a very few of them are actually used. > > > > One can use DT_AT_artificial to distinguish machine generated > temporaries and the .debug_loc ranges to decide whether to display the > variable. What happens if you're outside any of the ranges listed in .debug_loc - will the variable be listed or not or will this depend on DW_AT_artificial ? IMHO variables which have been created by a human should always be listed, but machine generated ones (since there can be a large number of them) should only be listed withing their lifetime ranges. -- Martin Baulig martin@gnome.org