Re: gdb/1465

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

The following reply was made to PR c++/1465; it has been noted by GNATS.

From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: carlton@kealia.com, gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: gdb/1465
Date: Wed, 26 Nov 2003 16:09:08 -0500 (EST)

 Here is some more analysis.  I figured out about 75% of this bug
 and then I reached the limits of my symbol table skills.
 
 gnuv2_value_rtti_type wants to find the rtti type for the static type "A".
 So it calls lookup_typename.
 
 The objfile for the main executable has one symtab.
 This symtab has a static block, as usual.
 This static block has the symbol for "struct A".
   I want to find this symbol.
 The namespace symbol for "namespace A" is in some other symbol table.
   I don't know or care which.
   I don't want to find this symbol!
 
 Here is the call tree for the type lookup:
 
   gnuv2_value_rtti_type
     lookup_typename
       lookup_symbol
         lookup_symbol_aux
           lookup_symbol_aux_local
           check_field
           current_language->la_lookup_symbol_nonlocal
             lookup_namespace_scope
               lookup_namespace_scope
               cp_lookup_symbol_namespace
                 cp_lookup_symbol_namespace
                 lookup_symbol_file
                   lookup_symbol_static                    [1]
                     lookup_symbol_aux_block
                       lookup_block_symbol
                   lookup_symbol_aux_block
                     lookup_block_symbol
                   lookup_symbol_global
                     lookup_symbol_aux_symtabs             [2]
                       lookup_block_symbol
                     lookup_symbol_aux_psymtabs
                       lookup_partial_symbol
                       lookup_block_symbol
                   lookup_possible_namespace_symbol        [3]
                     lookup_block_symbol
           lookup_symbol_aux_symtabs                       [4]
             lookup_block_symbol
           lookup_symbol_aux_psymtabs
             lookup_partial_symbol
             lookup_block_symbol
       lookup_primitive_typename
 
 It takes a while to grok this tree.  You might have to do what I did:
 start at the place where gnuv2_value_rtti_type calls lookup_typename
 and write the tree yourself.
 
 The key functions here are gnuv2_value_rtti_type, lookup_symbol_aux,
 and lookup_symbol_file.
 
 gnuv2_value_rtti_type specifies block = 0.  I think this is the bug.
 And then gdb goes through all those calls.
 
 Point [1] is supposed to find the static symbol.
   It doesn't match because block == 0 here!
 
 Point [2] is part of global symbol lookup.
   It looks in BLOCK_GLOBAL blocks.
   It's not supposed to match, and it doesn't.
 
 Point [3] is part of the new namespace code.
   It matches the synthetic symbol for "namespace A".
   That's where the wrong symbol gets returned to gnu2_value_rtti_type!
   The last working gdb was gdb HEAD 2003-09-11 19:30:00 UTC.
   In that gdb, point [3] does not exist, so it doesn't match.
   With the current gdb, point [3] matches.
 
 Point [4] is a catch-all matcher.
   It looks in all STATIC_BLOCK blocks in all symtabs in all objfiles.
   The comment says: "not strictly correct, but more useful than an error."
   In the last working gdb, point [4] picks up the match.
 
 The dwarf-2 reader creates these namespace symbols, but the stabs+
 reader does not.  With gcc 2.95.3 -gstabs+, gdb falls through point [3]
 without matching and proceeds to point [4], where it finds the right
 symbol.
 
 I think the real problem is the point where gnuv2_value_rtti_type
 specifies block=0.  Conceptually, that looks wrong to me.  gdb is
 looking up a type name and the type name might have different meanings
 in different scopes.  lookup_typename really needs a correct block
 argument.
 
 The problem is: there is no handy block pointer lying around in
 gnuv2_value_rtti_type, or anywhere in the call stack above it,
 for that matter.  Can someone help me out here?
 
 hpacc_value_rtti_type has the same structure, so it probably has
 the same bug.
 
 gnuv3_rtti_type calls lookup_symbol(domain=STRUCT_DOMAIN, block=0).  That's
 why the bug does not happen with gcc v3.  When domain==STRUCT_DOMAIN,
 lookup_symbol_file does not even call lookup_possible_namespace_symbol,
 so the search at [3] never happens.
 
 gnuv3_rtti_type is still flaky because it still specifies an incorrect
 block, so it still matches at [4] instead of [1].
 
 Another question: v2 searches in VAR_DOMAIN, and v3 searches in
 STRUCT_DOMAIN.  Why the difference?
 
 Also, the more I look at lookup_typename, the less I like it.  It's
 called in only a few places.  c-exp.y and objc-exp.y use
 "lookup_signed_typename" and "lookup_unsigned_typename" to parse
 "signed" and "unsigned" stuff.  The only valid uses of that are for
 primitive type names, and those are going to be very forgiving of the
 incorrect block scope.  And then gnuv2_rtti_type and
 hpacc_value_rtti_type call lookup_typename, and they are doing it wrong.
 And that's all the calls to lookup_typename.
 
 So my plan is:
 
 (1) Change gnuv2_value_rtti_type from lookup_typename to lookup_symbol.
 
 (2) Change both gnuv2_value_rtti_type and gnuv3_value_rtti_type
     to supply a proper block argument to lookup_symbol.  I need help
     with this part.
 
 (3) Add some code to both gnuv2_value_rtti_type and gnuv3_value_rtti_type
     to check the type that they are using.  If it's not TYPE_CODE_STRUCT
     (or similar) then print "rtti type botch".  I would rather show the
     user "rtti type botch" then show the user incorrect data values.
 
 (4) Write some test cases for this.
 
 Michael C