From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21906 invoked by alias); 13 Apr 2002 12:08:34 -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 21755 invoked from network); 13 Apr 2002 12:08:28 -0000 Received: from unknown (HELO localhost?merlin.xternal.fadata.bg) (217.9.226.246) by sources.redhat.com with SMTP; 13 Apr 2002 12:08:28 -0000 Received: (qmail 1185 invoked by uid 1000); 13 Apr 2002 12:08:22 -0000 To: Martin Baulig 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> From: Momchil Velikov Date: Sat, 13 Apr 2002 05:08:00 -0000 In-Reply-To: <86bscnesxy.fsf@einstein.home-of-linux.org> Message-ID: <873cxzdcnd.fsf@fadata.bg> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00228.txt.bz2 Martin Baulig writes: > Daniel Jacobowitz writes: > > > No. I'd strongly object to adding any DWARF-2 tags without at least > > discussing them with the DWARF committee (which is quite responsive, I > > believe). > > Yeah, good point. > > > Also, I believe that this should be entirely subsumed by .debug_loc. > > The first variable's value may no longer be available, but it has not > > actually gone out of scope, has it? We should list it but claim that > > its value is unavailable. > > It has actually gone out of scope. 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. > 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.