This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/1465
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 26 Nov 2003 21:18:01 -0000
- Subject: Re: gdb/1465
- Reply-to: 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