This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
references to uninitialized static const members
- From: david carlton <carlton at math dot stanford dot edu>
- To: gdb-patches at sources dot redhat dot com
- Cc: carlton at math dot stanford dot edu
- Date: Tue, 6 Aug 2002 11:59:36 -0700
- Subject: references to uninitialized static const members
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