This is the mail archive of the
mailing list for the GDB project.
Re: Lifetime of local variables
- From: Jim Blandy <jimb at redhat dot com>
- To: Martin Baulig <martin at gnome dot org>
- Cc: gdb at sources dot redhat dot com
- Date: 16 Apr 2002 17:06:40 -0500
- Subject: Re: Lifetime of local variables
- References: <email@example.com>
Martin Baulig <firstname.lastname@example.org> 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.