From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2532 invoked by alias); 16 Apr 2002 22:07:26 -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 2491 invoked from network); 16 Apr 2002 22:07:21 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 16 Apr 2002 22:07:21 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 9D12A5EA13; Tue, 16 Apr 2002 17:06:40 -0500 (EST) To: Martin Baulig Cc: gdb@sources.redhat.com Subject: Re: Lifetime of local variables References: <86u1qghdp5.fsf@einstein.home-of-linux.org> From: Jim Blandy Date: Tue, 16 Apr 2002 15:07:00 -0000 In-Reply-To: <86u1qghdp5.fsf@einstein.home-of-linux.org> Message-ID: 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/msg00276.txt.bz2 Martin Baulig writes: > I was recently working a bit on debugging support for C# (using Mono) > and I need a way to tell GDB about the lifetime of local variables. In > C#, the JIT engine may decide to store two different variables at the > same stack offset if they aren't used throughout the whole function. > > Now I was wondering how to do this - DWARF 2 already has a > `DW_AT_begin_scope' but unfortunately no `DW_AT_end_scope' - can we > add this or something similar as a GNU extension ? I'm going to weigh in here with the other folks: - You should use Dwarf location lists to show where a variable is live, and where it lives when it's live. They're designed for exactly this purpose. - You should not emit debugging info for compiler-generated temporaries at all. Those are more like registers or scratch stack slots than variables. Of course, Mono JIT implementers will want to examine the temporaries. But it seems to me that GDB's support for printing machine registers and dumping stack frames should do the trick there. Those are what the GCC people use. Since the temporary variables' names are meaningless (right?), what's the difference between looking at a temporary and looking at a machine register? I'm a little leery of extending DW_AT_artificial's meaning to mark compiler-generated temporaries; those are different from things like `this', default constructors, and so on. > After looking at the code, I found out that `struct symbol' contains a > `ranges' field which seems to do exactly what I want - but this field > isn't used anywhere. That's deprecated; I really don't think we want to revive it.