Lifetime of local variables

Lifetime of local variables

[Martin Baulig]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

Hi,

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 ?

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.

The following patch

* adds a new DWARF 2 attribute DW_AT_end_scope to specify the end of
  a local variable's scope.

* initializes SYMBOL_RANGES() in dwarf2read.c if DW_AT_begin_scope and
  DW_AT_end_scope are specified.

  [FIXME: According to the DWARF 2 specification, this attribute takes
          an offset (DW_FROM_data), not an address - but I found now
          way to get the current frame's address in new_symbol(), this
          needs to be fixed.]

* checks whether the current PC is within the symbol's SYMBOL_RANGES()
  when listing the local variables of a function and when printing a
  variable.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gdb-variable-scopes.patch --]
[-- Type: text/x-patch, Size: 5169 bytes --]

Index: include/elf/ChangeLog
===================================================================
RCS file: /cvs/src/src/include/elf/ChangeLog,v
retrieving revision 1.121
diff -u -u -p -r1.121 ChangeLog
--- include/elf/ChangeLog	13 Feb 2002 18:14:48 -0000	1.121
+++ include/elf/ChangeLog	12 Apr 2002 19:50:31 -0000
@@ -1,3 +1,7 @@
+2002-04-12  Martin Baulig  <martin@gnome.org>
+
+	* dwarf2.h (DW_AT_end_scope): Added as GNU extension.
+
 2002-02-13  Matt Fredette  <fredette@netbsd.org>
 
 	* m68k.h (EF_M68000): Define.
Index: include/elf/dwarf2.h
===================================================================
RCS file: /cvs/src/src/include/elf/dwarf2.h,v
retrieving revision 1.8
diff -u -u -p -r1.8 dwarf2.h
--- include/elf/dwarf2.h	28 Jan 2002 23:26:53 -0000	1.8
+++ include/elf/dwarf2.h	12 Apr 2002 19:50:32 -0000
@@ -328,6 +328,8 @@ enum dwarf_attribute
     DW_AT_src_coords = 0x2104,
     DW_AT_body_begin = 0x2105,
     DW_AT_body_end   = 0x2106,
+    DW_AT_end_scope  = 0x2121,
+    
     /* VMS Extensions.  */
     DW_AT_VMS_rtnbeg_pd_address = 0x2201
   };
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.2421
diff -u -u -p -r1.2421 ChangeLog
--- gdb/ChangeLog	12 Apr 2002 07:37:17 -0000	1.2421
+++ gdb/ChangeLog	12 Apr 2002 19:50:38 -0000
@@ -1,3 +1,14 @@
+2002-04-12  Martin Baulig  <martin@gnome.org>
+
+	* dwarf2read.c (new_symbol): If DW_AT_start_scope and DW_AT_end_scope
+	are specified, set SYMBOL_RANGES().
+
+	* findvar.c (read_var_value): Check whether the current PC is within
+	the SYMBOL_RANGES(), return NULL if not.
+
+	* stack.c (print_block_frame_locals): Only print vars if the current PC
+	is in their SYMBOL_RANGES().
+
 2002-04-12  Kevin Buettner  <kevinb@redhat.com>
 
 	From Jimi X <jimix@watson.ibm.com>:
Index: gdb/dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.52
diff -u -u -p -r1.52 dwarf2read.c
--- gdb/dwarf2read.c	4 Apr 2002 22:26:43 -0000	1.52
+++ gdb/dwarf2read.c	12 Apr 2002 19:50:44 -0000
@@ -4394,6 +4394,19 @@ new_symbol (struct die_info *die, struct
 		add_symbol_to_list (sym, list_in_scope);
 	      break;
 	    }
+	  attr = dwarf_attr (die, DW_AT_start_scope);
+	  attr2 = dwarf_attr (die, DW_AT_end_scope);
+	  if (attr && attr2)
+	    {
+	      struct range_list *r = (struct range_list *)
+		obstack_alloc (&objfile->type_obstack,
+			       sizeof (struct range_list));
+
+	      r->start = DW_ADDR (attr);
+	      r->end = DW_ADDR (attr2);
+
+	      SYMBOL_RANGES (sym) = r;
+	    }
 	  attr = dwarf_attr (die, DW_AT_location);
 	  if (attr)
 	    {
Index: gdb/findvar.c
===================================================================
RCS file: /cvs/src/src/gdb/findvar.c,v
retrieving revision 1.31
diff -u -u -p -r1.31 findvar.c
--- gdb/findvar.c	9 Apr 2002 03:06:13 -0000	1.31
+++ gdb/findvar.c	12 Apr 2002 19:50:45 -0000
@@ -417,9 +417,11 @@ struct value *
 read_var_value (register struct symbol *var, struct frame_info *frame)
 {
   register struct value *v;
+  register struct range_list *r;
   struct type *type = SYMBOL_TYPE (var);
   CORE_ADDR addr;
   register int len;
+  int range_ok = 0;
 
   v = allocate_value (type);
   VALUE_LVAL (v) = lval_memory;	/* The most likely possibility.  */
@@ -429,6 +431,23 @@ read_var_value (register struct symbol *
 
   if (frame == NULL)
     frame = selected_frame;
+
+  if (!SYMBOL_RANGES (var))
+    range_ok = 1;
+  else
+    {
+      for (r = SYMBOL_RANGES (var); r; r = r->next)
+	{
+	  if (r->start <= frame->pc && r->end > frame->pc)
+	    {
+	      range_ok = 1;
+	      break;
+	    }
+	}
+    }
+
+  if (!range_ok)
+    return NULL;
 
   switch (SYMBOL_CLASS (var))
     {
Index: gdb/stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.33
diff -u -u -p -r1.33 stack.c
--- gdb/stack.c	10 Apr 2002 23:32:33 -0000	1.33
+++ gdb/stack.c	12 Apr 2002 19:50:47 -0000
@@ -1173,14 +1173,36 @@ print_block_frame_locals (struct block *
 	case LOC_REGISTER:
 	case LOC_STATIC:
 	case LOC_BASEREG:
-	  values_printed = 1;
-	  for (j = 0; j < num_tabs; j++)
-	    fputs_filtered ("\t", stream);
-	  fputs_filtered (SYMBOL_SOURCE_NAME (sym), stream);
-	  fputs_filtered (" = ", stream);
-	  print_variable_value (sym, fi, stream);
-	  fprintf_filtered (stream, "\n");
-	  break;
+	  {
+	    struct range_list *r;
+	    int range_ok = 0;
+
+	    if (!SYMBOL_RANGES (sym))
+	      range_ok = 1;
+	    else
+	      {
+		for (r = SYMBOL_RANGES (sym); r; r = r->next)
+		  {
+		    if (r->start <= fi->pc && r->end > fi->pc)
+		      {
+			range_ok = 1;
+			break;
+		      }
+		  }
+	      }
+
+	    if (range_ok)
+	      {
+		values_printed = 1;
+		for (j = 0; j < num_tabs; j++)
+		  fputs_filtered ("\t", stream);
+		fputs_filtered (SYMBOL_SOURCE_NAME (sym), stream);
+		fputs_filtered (" = ", stream);
+		print_variable_value (sym, fi, stream);
+		fprintf_filtered (stream, "\n");
+	      }
+	    break;
+	  }
 
 	default:
 	  /* Ignore symbols which are not locals.  */

[-- Attachment #3: Type: text/plain, Size: 37 bytes --]


-- 
Martin Baulig
martin@gnome.org

Re: Lifetime of local variables

[Daniel Jacobowitz]

On Fri, Apr 12, 2002 at 10:19:50PM +0200, Martin Baulig wrote:
> Hi,
> 
> 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 ?

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).

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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Lifetime of local variables

[Martin Baulig]

Daniel Jacobowitz <drow@mvista.com> 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 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.

Btw. are there any plans to implement .debug_loc anytime soon, I need
this for something else ?

-- 
Martin Baulig
martin@gnome.org

Re: Lifetime of local variables

[Momchil Velikov]

Martin Baulig <martin@gnome.org> writes:

> Daniel Jacobowitz <drow@mvista.com> 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.

Re: Lifetime of local variables

[Martin Baulig]

Momchil Velikov <velco@fadata.bg> 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

Re: Lifetime of local variables

[Daniel Jacobowitz]

On Sat, Apr 13, 2002 at 01:31:05PM +0200, Martin Baulig wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> > 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 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.

What business does the JIT have actually creating local variables
(rather than temporaries, which don't get names)?  I don't understand.

> Btw. are there any plans to implement .debug_loc anytime soon, I need
> this for something else ?

I believe it's in progress.

On Sat, Apr 13, 2002 at 02:42:14PM +0200, Martin Baulig wrote:
> Momchil Velikov <velco@fadata.bg> writes:
> > 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.

We don't know yet, since DW_AT_artificial is currently only used for
method arguments (and methods, but that patch is pending).  Once we've
got .debug_loc we can decide, but this seems reasonable to me.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Lifetime of local variables

[Martin Baulig]

Daniel Jacobowitz <drow@mvista.com> writes:

> On Sat, Apr 13, 2002 at 01:31:05PM +0200, Martin Baulig wrote:
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > 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 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.
> 
> What business does the JIT have actually creating local variables
> (rather than temporaries, which don't get names)?  I don't understand.

What's the difference between a local variable and a temporary variable ?

> > Btw. are there any plans to implement .debug_loc anytime soon, I need
> > this for something else ?
> 
> I believe it's in progress.

Well, this is probably the correct place to put this (and then use
DW_AT_artificial or something like this to make the variables
disappear outside their lifetime).

> On Sat, Apr 13, 2002 at 02:42:14PM +0200, Martin Baulig wrote:
> > Momchil Velikov <velco@fadata.bg> writes:
> > > 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.
> 
> We don't know yet, since DW_AT_artificial is currently only used for
> method arguments (and methods, but that patch is pending).  Once we've
> got .debug_loc we can decide, but this seems reasonable to me.
> 
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 

-- 
Martin Baulig
martin@gnome.org

Re: Lifetime of local variables

[Daniel Jacobowitz]

On Sat, Apr 13, 2002 at 08:52:21PM +0200, Martin Baulig wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Sat, Apr 13, 2002 at 01:31:05PM +0200, Martin Baulig wrote:
> > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > > 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 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.
> > 
> > What business does the JIT have actually creating local variables
> > (rather than temporaries, which don't get names)?  I don't understand.
> 
> What's the difference between a local variable and a temporary variable ?

There's no reason for temporaries to have names, or to appear in debug
info at all.  I don't see why you need them.

> > > Btw. are there any plans to implement .debug_loc anytime soon, I need
> > > this for something else ?
> > 
> > I believe it's in progress.
> 
> Well, this is probably the correct place to put this (and then use
> DW_AT_artificial or something like this to make the variables
> disappear outside their lifetime).

Sounds good to me.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Lifetime of local variables

[Momchil Velikov]

Martin Baulig <martin@gnome.org> writes:

> Daniel Jacobowitz <drow@mvista.com> writes:
> > What business does the JIT have actually creating local variables
> > (rather than temporaries, which don't get names)?  I don't understand.
> 
> What's the difference between a local variable and a temporary variable ?

The difference is that the person who debugs a program generally wants
to look at the local variables and generally doesn't want to look at
compiler temporaries. For the latter case, registers/memory dump seems
appropriate or, for the case of CLI, the "evaluation stack" and the
"local variable array".

Regards,
-velco

Re: Lifetime of local variables

[Daniel Berlin]

On Fri, 2002-04-12 at 16:19, Martin Baulig wrote:
> Hi,
> 
> 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 ?

No need.
Just use DWARF2 location lists to describe where the variables are.
--Dan

Re: Lifetime of local variables

[Daniel Berlin]

On 12 Apr 2002, Martin Baulig wrote:

> Hi,
> 
> 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 ?
> 
> 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.

And the reason ranges isn't use anywhere is because it was part of a 
hackish extension to STABS for live range support.
The code to produce the live range extensions to STABS was never 
added to gcc in any public release.

If you are using DWARF2, you already can describe variable 
lifetimes/changing locations using location lists. 

While it would seem GDB has no support for them at current, rest assured 
that 
1. Patches to support location expressions, which is what location lists 
are made up of, have been submitted.
2. Location lists are a trivial extension of #1.

In fact, I already have support for them sitting in a patch on my 
harddrive, i'm waiting for the location expression support to be approved 
before i submit location list support.

GCC's cfg-branch will now produce location lists for optimized code, and I 
added support to readelf for reading them.

Re: Lifetime of local variables

[Jim Blandy]

Martin Baulig <martin@gnome.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.