This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
how long should symbols remain LOC_UNRESOLVED?
- From: David Carlton <carlton at math dot stanford dot edu>
- To: gdb <gdb at sources dot redhat dot com>
- Cc: carlton at math dot stanford dot edu
- Date: Mon, 12 Aug 2002 11:28:24 -0700
- Subject: how long should symbols remain LOC_UNRESOLVED?
I'm trying to understand the behaviour of GDB when debugging files
like the following:
// Let's put in lots and lots of static members.
class C {
public:
int ns1;
static int a;
static const int b;
static char *c;
static const char *d;
static const int e = 153;
};
extern const int f;
extern const int g = 1;
extern const char *h;
int main()
{
C theC;
}
So there are lots of symbols that don't ever get defined or
referenced: the static members, and the extern variables.
Nonetheless, if I compile this with GCC 3.1 (g++ -g, which implies
-gdwarf-2) then GCC seems to be emitting debugging information for
some of the variables: it emits debugging information for the class,
as expected (though I think that what it emits isn't quite right, but
in a relatively harmless way), then some type debugging information
that I don't entirely understand but that I don't think hurts, then
debugging information for main(), and then, strangely, at the end it
separately emits debugging information for C::b (and maybe for some of
the other variables, but certainly not all of them).
It seems to me unfortunate that GCC generates debugging information
for C::b, given that it's neither defined nor referenced, and perhaps
this should be reported as a bug to GCC. I'm not entirely convinced
that GCC is doing anything illegal in doing so, however (the debugging
information in question is flagged as a declaration).
Anyways, setting aside the question of whether or not GCC is wrong in
doing so, this causes GDB to generate a symbol whose SYMBOL_CLASS is
LOC_UNRESOLVED. A comment in the code at dwarf2read.c:4794 says that:
/* We do not know the address of this symbol.
If it is an external symbol and we have type information
for it, enter the symbol as a LOC_UNRESOLVED symbol.
The address of the variable will then be determined from
the minimal symbol table whenever the variable is
referenced. */
which suggests that the address will be determined from the minimal
symbol table. But that never occurs.
I haven't delved too deeply into GDB's minimal symbol table, so I'm
about to ask some naive questions; forgive me. Here they are:
* What is the minimal symbol table? Am I correct in thinking that it
contains basic information about those global symbols that the
linker needs to know about? (Which could presumably happen because
they're defined in this file or referred to in this file.)
* Is there an assumption in GDB's code that, if a symbol is created
whose SYMBOL_CLASS is LOC_UNRESOLVED, then that symbol should be
present in the minimal symbol table as well?
* Does GDB require help from the compiler to keep that assumption
valid? E.g. is GDB assuming that the compiler will never generate
debugging information for declarations of external variables that
are never actually referred to in the code?
* If so, is that a reasonable assumption by GDB?
Thanks for any light anybody can shed on this.
David Carlton
carlton@math.stanford.edu