references to uninitialized static const members

david carlton carlton@math.stanford.edu
Tue Aug 6 11:59:00 GMT 2002


If I compile code using g++ -gdwarf-2 that contains a class with a
static const member that isn't initialized, and then print it out, GDB
says: "Cannot access memory at address 0x0".  (I've submitted some
specific instructions for generating this bug with PR gdb/635.)

I'm no C++ expert, but failing to initialize your static const members
doesn't sound like a very bright idea to me.  Nonetheless, it seems to
be legal C++ (g++ doesn't complain), so GDB should handle it better
than it does.  The problem is that, in values.c(value_static_field),
the symbol returned by lookup_symbol has the class LOC_UNRESOLVED; the
comment in the code there claims that "Anything static that isn't a
constant, has an address", but that fails in this case.

I'm including a patch below that tests for LOC_UNRESOLVED and, if so,
returns NULL.  This seems the best way to handle the situation; it's
the same value that gets returned returned by value_static_field() if
you compile the same code with g++ -gstabs.  (Though for a different
reason: if you do -gstabs, the symbol table lookup fails in the first
place.)  And cp-valprint.c(cp_print_value_fields) treats a return
value of NULL as meaning that the member in question has been
optimized out, which seems like a reasonable response.  The parallel
code in jv-valprint.c and p-valprint.c does that too.

There is some code in valops.c that isn't particularly happy if it
gets a NULL response from value_static_field(); I haven't looked at it
closely to see if that code should be a bit more forgiving.  Given
that there already seem to be legitimate reasons for
value_static_field() to return NULL, and that, in this case, the
alternative to returning NULL is to signal a bad memory access, this
patch does seem to strictly improve the situation.

I didn't see any new regressions (other than chd.chill/chexp.exp not
being willing to set the language to "chill", and I don't think that's
my fault!).

2002-08-06  david carlton  <carlton@math.stanford.edu>

	* values.c (value_static_field): Test to make sure that the
	location of the symbol isn't LOC_UNRESOLVED.

Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.38
diff -u -p -r1.38 values.c
--- values.c	3 Jul 2002 21:27:55 -0000	1.38
+++ values.c	6 Aug 2002 18:39:54 -0000
@@ -824,8 +824,13 @@ value_static_field (struct type *type, i
 	}
       else
 	{
+	  /* This can happen under g++ -gdwarf-2 if the static field
+	     is an uninitialized const static field.  (Why one would
+	     write code with such fields is another question...) */
+	  if (SYMBOL_CLASS (sym) == LOC_UNRESOLVED)
+	    return NULL;
  	  /* Anything static that isn't a constant, has an address */
- 	  if (SYMBOL_CLASS (sym) != LOC_CONST)
+ 	  else if (SYMBOL_CLASS (sym) != LOC_CONST)
  	    {
 	      addr = SYMBOL_VALUE_ADDRESS (sym);
 	      sect = SYMBOL_BFD_SECTION (sym);


David Carlton
carlton@math.stanford.edu



More information about the Gdb-patches mailing list