This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/17004] print base::operator char * passes in cpexprs.exp, but only accidentally
- From: "dje at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sat, 31 May 2014 01:03:49 +0000
- Subject: [Bug c++/17004] print base::operator char * passes in cpexprs.exp, but only accidentally
- Auto-submitted: auto-generated
- References: <bug-17004-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17004
--- Comment #1 from dje at google dot com ---
SamB pointed out on IRC that converting "base::operator char *" to
"base::operatorchar *" can be ambiguous if the class also really has a member
base::operatorchar.
Plus it's not clear to me how much canonicalization is strictly adhered to and
how much gdb just gets away with bugs because of how it works.
E.g. dwarf2read.c:mapped_index_string_hash doesn't ignore spaces.
So if the canonicalization is wrong, the symbol won't be found in the index.
However, it probably won't ever matter, at least in the case of member
functions, because gdb will always lookup the class first, and thus expand the
symbol table containing the class before it ever looks up a member function in
that class. And because gdb looks in already expanded symbol tables before
trying the index, any improper canonicalization that prevents symbols being
found in the index won't ever matter.
Another reason why such bugs can get missed is because of the bazillion
different ways gdb tries to lookup a symbol if one way fails. Here again a
lookup in the index can errantly fail, but because the symtab got expanded
during the first attempt then when gdb tries to lookup the symbol in a
different way (see, e.g., cp-namespace.c) subsequent lookups will get to use
expanded symtabs.
This matters because I'm looking into having gdb *only* use the index for
lookups. Still don't know if this path will be fruitful, but iterating over
already expanded symtabs when .gdb_index already knows exactly which symtabs to
look at feels promising.
[It also matters of course because it just makes gdb hard to hack on.]
--
You are receiving this mail because:
You are on the CC list for the bug.