No description
ee93cd5e1e
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.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| lt~obsolete.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.