PATCH: gdb/709, C++ static members

PATCH: gdb/709, C++ static members

[Daniel Jacobowitz]

David, your earlier patch:

        * values.c (value_static_field): Treat an unresolved location the
        same as a nonexistent symbol.  Fix PR gdb/635.

pointed me in the right direction for this fix.  As you may have pointed out
at the time, read_var_value does basically the same thing your fix does in
that case.  It turns out that there's some other cases - this particular one
was LOC_CONST_BYTES - where read_var_value does the right thing and
value_static_field doesn't.  So I just had value_static_field call
read_var_value, which fixes your testcase and also a new one I'll post later
for gdb/709.

Committed, since static members are a C++ thing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-09-18  Daniel Jacobowitz  <drow@mvista.com>

	Fix PR gdb/709
	* values.c (value_static_field): Call read_var_value.

Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.40
diff -u -p -r1.40 values.c
--- values.c	24 Aug 2002 00:21:35 -0000	1.40
+++ values.c	18 Sep 2002 15:23:14 -0000
@@ -800,25 +800,19 @@ unpack_pointer (struct type *type, char 
 struct value *
 value_static_field (struct type *type, int fieldno)
 {
-  CORE_ADDR addr;
-  asection *sect;
+  struct value *retval;
+
   if (TYPE_FIELD_STATIC_HAS_ADDR (type, fieldno))
     {
-      addr = TYPE_FIELD_STATIC_PHYSADDR (type, fieldno);
-      sect = NULL;
+      retval = value_at (TYPE_FIELD_TYPE (type, fieldno),
+			 TYPE_FIELD_STATIC_PHYSADDR (type, fieldno),
+			 NULL);
     }
   else
     {
       char *phys_name = TYPE_FIELD_STATIC_PHYSNAME (type, fieldno);
       struct symbol *sym = lookup_symbol (phys_name, 0, VAR_NAMESPACE, 0, NULL);
-      /* In some cases (involving uninitalized, unreferenced static
-	 const integral members), g++ -gdwarf-2 can emit debugging
-	 information giving rise to symbols whose SYMBOL_CLASS is
-	 LOC_UNRESOLVED.  In that case, do a minimal symbol lookup.
-	 If it returns a useful value, then the symbol was defined
-	 elsewhere, so we use that information.  Otherwise, return
-	 NULL. */
-      if (sym == NULL || SYMBOL_CLASS (sym) == LOC_UNRESOLVED)
+      if (sym == NULL)
 	{
 	  /* With some compilers, e.g. HP aCC, static data members are reported
 	     as non-debuggable symbols */
@@ -827,27 +821,25 @@ value_static_field (struct type *type, i
 	    return NULL;
 	  else
 	    {
-	      addr = SYMBOL_VALUE_ADDRESS (msym);
-	      sect = SYMBOL_BFD_SECTION (msym);
+	      retval = value_at (TYPE_FIELD_TYPE (type, fieldno),
+				 SYMBOL_VALUE_ADDRESS (msym),
+				 SYMBOL_BFD_SECTION (msym));
 	    }
 	}
       else
 	{
- 	  /* Anything static that isn't a constant, has an address */
- 	  if (SYMBOL_CLASS (sym) != LOC_CONST)
- 	    {
-	      addr = SYMBOL_VALUE_ADDRESS (sym);
-	      sect = SYMBOL_BFD_SECTION (sym);
-	    }
- 	  /* However, static const's do not, the value is already known.  */
- 	  else
- 	    {
- 	      return value_from_longest (TYPE_FIELD_TYPE (type, fieldno), SYMBOL_VALUE (sym));
- 	    }
+	  /* SYM should never have a SYMBOL_CLASS which will require
+	     read_var_value to use the FRAME parameter.  */
+	  if (symbol_read_needs_frame (sym))
+	    warning ("static field's value depends on the current "
+		     "frame - bad debug info?");
+	  retval = read_var_value (sym, NULL);
  	}
-      SET_FIELD_PHYSADDR (TYPE_FIELD (type, fieldno), addr);
+      if (retval && VALUE_LVAL (retval) == lval_memory)
+	SET_FIELD_PHYSADDR (TYPE_FIELD (type, fieldno),
+			    VALUE_ADDRESS (retval));
     }
-  return value_at (TYPE_FIELD_TYPE (type, fieldno), addr, sect);
+  return retval;
 }
 
 /* Change the enclosing type of a value object VAL to NEW_ENCL_TYPE.  

Re: PATCH: gdb/709, C++ static members

[David Carlton]

On Wed, 18 Sep 2002 11:40:26 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> David, your earlier patch:
>         * values.c (value_static_field): Treat an unresolved location the
>         same as a nonexistent symbol.  Fix PR gdb/635.

> pointed me in the right direction for this fix.  As you may have
> pointed out at the time, read_var_value does basically the same
> thing your fix does in that case.  It turns out that there's some
> other cases - this particular one was LOC_CONST_BYTES - where
> read_var_value does the right thing and value_static_field doesn't.
> So I just had value_static_field call read_var_value, which fixes
> your testcase and also a new one I'll post later for gdb/709.

Interesting.  I definitely want to think more about whose job it
should be to handle LOC_UNRESOLVED - it seems plausible that
LOC_UNRESOLVED symbols should never be allowed to escape from
lookup_symbol - but now it seems that I have more location classes to
consider.  Hmm.

David Carlton
carlton@math.stanford.edu

Re: PATCH: gdb/709, C++ static members

[Daniel Jacobowitz]

On Wed, Sep 18, 2002 at 11:40:26AM -0400, Daniel Jacobowitz wrote:
> David, your earlier patch:
> 
>         * values.c (value_static_field): Treat an unresolved location the
>         same as a nonexistent symbol.  Fix PR gdb/635.
> 
> pointed me in the right direction for this fix.  As you may have pointed out
> at the time, read_var_value does basically the same thing your fix does in
> that case.  It turns out that there's some other cases - this particular one
> was LOC_CONST_BYTES - where read_var_value does the right thing and
> value_static_field doesn't.  So I just had value_static_field call
> read_var_value, which fixes your testcase and also a new one I'll post later
> for gdb/709.
> 
> Committed, since static members are a C++ thing.

And on the branch, since it got reported in GNATS twice in one day...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer