This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]