aboutsummaryrefslogtreecommitdiff
path: root/gdb/block.c
diff options
context:
space:
mode:
authorKeith Seitz <keiths@redhat.com>2015-06-26 10:27:45 -0700
committerKeith Seitz <keiths@redhat.com>2015-06-26 10:27:45 -0700
commitee93cd5e1e61e5739a1a44e0d1d166ae09d04dc2 (patch)
treebe7f1af92bf4695f25b2dabbda487dcc7e204f81 /gdb/block.c
parentfc637f04c741b08726cc1631428bf094235ecb4e (diff)
downloadgdb-ee93cd5e1e61e5739a1a44e0d1d166ae09d04dc2.zip
gdb-ee93cd5e1e61e5739a1a44e0d1d166ae09d04dc2.tar.gz
gdb-ee93cd5e1e61e5739a1a44e0d1d166ae09d04dc2.tar.bz2
PR 16253 revisited
Last year a patch was submitted/approved/commited to eliminate symbol_matches_domain which was causing this problem. It was later reverted because it introduced a (severe) performance regression. Recap: (gdb) list 1 enum e {A,B,C} e; 2 int main (void) { return 0; } 3 (gdb) p e Attempt to use a type name as an expression The parser attempts to find a symbol named "e" of VAR_DOMAIN. This gets passed down through lookup_symbol and (eventually) into block_lookup_symbol_primary, which iterates over the block's dictionary of symbols: for (sym = dict_iter_name_first (block->dict, name, &dict_iter); sym != NULL; sym = dict_iter_name_next (name, &dict_iter)) { if (symbol_matches_domain (SYMBOL_LANGUAGE (sym), SYMBOL_DOMAIN (sym), domain)) return sym; } The problem here is that we have a symbol named "e" in both STRUCT_DOMAIN and VAR_DOMAIN, and for languages like C++, Java, and Ada, where a tag name may be used as an implicit typedef of the type, symbol_matches_domain ignores the difference between VAR_DOMAIN and STRUCT_DOMAIN. As it happens, the STRUCT_DOMAIN symbol is found first, considered a match, and that symbol is returned to the parser, eliciting the (now dreaded) error message. Since this bug exists specifically because we have both STRUCT and VAR_DOMAIN symbols in a given block/CU, this patch rather simply/naively changes block_lookup_symbol_primary so that it continues to search for an exact domain match on the symbol if symbol_matches_domain returns a symbol which does not exactly match the requested domain. This "fixes" the immediate problem, but admittedly might uncover other, related bugs. [Paranoia?] However, it causes no regressions (functional or performance) in the test suite. A similar change has been made to block_lookup_symbol for other cases in which this bug might appear. The tests from the previous submission have been resurrected and updated. However since we can still be given a matching symbol with a different domain than requested, we cannot say that a symbol "was not found." The error messages today will still be the (dreaded) "Attempt to use a type name..." ChangeLog PR 16253 * block.c (block_lookup_symbol): For non-function blocks, continue to search for a symbol with an exact domain match Otherwise, return any previously found "best domain" symbol. (block_lookup_symbol_primary): Likewise. testsuite/ChangeLog PR 16253 * gdb.cp/var-tag-2.cc: New file. * gdb.cp/var-tag-3.cc: New file. * gdb.cp/var-tag-4.cc: New file. * gdb.cp/var-tag.cc: New file. * gdb.cp/var-tag.exp: New file.
Diffstat (limited to 'gdb/block.c')
-rw-r--r--gdb/block.c31
1 files changed, 25 insertions, 6 deletions
diff --git a/gdb/block.c b/gdb/block.c
index 79a8f19..f7621aa 100644
--- a/gdb/block.c
+++ b/gdb/block.c
@@ -739,13 +739,21 @@ block_lookup_symbol (const struct block *block, const char *name,
if (!BLOCK_FUNCTION (block))
{
+ struct symbol *other = NULL;
+
ALL_BLOCK_SYMBOLS_WITH_NAME (block, name, iter, sym)
{
+ if (SYMBOL_DOMAIN (sym) == domain)
+ return sym;
+ /* This is a bit of a hack, but symbol_matches_domain might ignore
+ STRUCT vs VAR domain symbols. So if a matching symbol is found,
+ make sure there is no "better" matching symbol, i.e., one with
+ exactly the same domain. PR 16253. */
if (symbol_matches_domain (SYMBOL_LANGUAGE (sym),
SYMBOL_DOMAIN (sym), domain))
- return sym;
+ other = sym;
}
- return NULL;
+ return other;
}
else
{
@@ -753,7 +761,10 @@ block_lookup_symbol (const struct block *block, const char *name,
list; this loop makes sure to take anything else other than
parameter symbols first; it only uses parameter symbols as a
last resort. Note that this only takes up extra computation
- time on a match. */
+ time on a match.
+ It's hard to define types in the parameter list (at least in
+ C/C++) so we don't do the same PR 16253 hack here that is done
+ for the !BLOCK_FUNCTION case. */
struct symbol *sym_found = NULL;
@@ -779,23 +790,31 @@ struct symbol *
block_lookup_symbol_primary (const struct block *block, const char *name,
const domain_enum domain)
{
- struct symbol *sym;
+ struct symbol *sym, *other;
struct dict_iterator dict_iter;
/* Verify BLOCK is STATIC_BLOCK or GLOBAL_BLOCK. */
gdb_assert (BLOCK_SUPERBLOCK (block) == NULL
|| BLOCK_SUPERBLOCK (BLOCK_SUPERBLOCK (block)) == NULL);
+ other = NULL;
for (sym = dict_iter_name_first (block->dict, name, &dict_iter);
sym != NULL;
sym = dict_iter_name_next (name, &dict_iter))
{
+ if (SYMBOL_DOMAIN (sym) == domain)
+ return sym;
+
+ /* This is a bit of a hack, but symbol_matches_domain might ignore
+ STRUCT vs VAR domain symbols. So if a matching symbol is found,
+ make sure there is no "better" matching symbol, i.e., one with
+ exactly the same domain. PR 16253. */
if (symbol_matches_domain (SYMBOL_LANGUAGE (sym),
SYMBOL_DOMAIN (sym), domain))
- return sym;
+ other = sym;
}
- return NULL;
+ return other;
}
/* See block.h. */