2018-01-01 05:43:02 +01:00
|
|
|
# Copyright 2014-2018 Free Software Foundation, Inc.
|
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.
2015-06-26 19:27:45 +02:00
|
|
|
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
# This file is part of the gdb testsuite
|
|
|
|
|
|
|
|
# Test expressions in which variable names shadow tag names.
|
|
|
|
|
|
|
|
if {[skip_cplus_tests]} { continue }
|
|
|
|
|
|
|
|
standard_testfile var-tag.cc var-tag-2.cc var-tag-3.cc var-tag-4.cc
|
|
|
|
|
2016-12-23 17:52:18 +01:00
|
|
|
if {[prepare_for_testing "failed to prepare" $testfile \
|
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.
2015-06-26 19:27:45 +02:00
|
|
|
[list $srcfile $srcfile2 $srcfile3 $srcfile4] {debug c++}]} {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
proc do_global_tests {lang} {
|
|
|
|
set invalid_print "Attempt to use a type name as an expression"
|
2015-07-30 20:52:49 +02:00
|
|
|
|
|
|
|
if {$lang == "c++"} {
|
2015-09-24 02:12:07 +02:00
|
|
|
set opt_underlying "(: unsigned (int|short|char) )?"
|
2015-07-30 20:52:49 +02:00
|
|
|
} else {
|
|
|
|
set opt_underlying ""
|
2015-07-30 23:20:01 +02:00
|
|
|
}
|
2015-07-30 20:52:49 +02:00
|
|
|
set ptypefmt "type = (class|enum|union|struct) %s $opt_underlying{.*}"
|
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.
2015-06-26 19:27:45 +02:00
|
|
|
|
|
|
|
with_test_prefix $lang {
|
|
|
|
gdb_test_no_output "set language $lang"
|
|
|
|
gdb_test "ptype C" "type = class C {.*}"
|
|
|
|
gdb_test "print E" "= a"
|
2015-07-30 20:52:49 +02:00
|
|
|
gdb_test "ptype E" "type = enum E $opt_underlying{.*}"
|
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.
2015-06-26 19:27:45 +02:00
|
|
|
gdb_test "print S" "= {<No data fields>}"
|
|
|
|
gdb_test "ptype S" "type = struct S {.*}"
|
|
|
|
gdb_test "print U" "= {.*}"
|
|
|
|
gdb_test "ptype U" "type = union U {.*}"
|
|
|
|
gdb_test "print cc" "= {.*}"
|
|
|
|
gdb_test "ptype cc" "type = class CC {.*}"
|
|
|
|
gdb_test "print CC" [format $invalid_print "CC"]
|
|
|
|
gdb_test "ptype CC" [format $ptypefmt "CC"]
|
|
|
|
gdb_test "print ss" "= {<No data fields>}"
|
|
|
|
gdb_test "ptype ss" "type = struct SS {.*}"
|
|
|
|
gdb_test "print SS" [format $invalid_print "SS"]
|
|
|
|
gdb_test "ptype SS" [format $ptypefmt "SS"]
|
|
|
|
gdb_test "print ee" "= .*"
|
2015-07-30 20:52:49 +02:00
|
|
|
gdb_test "ptype ee" "type = enum EE $opt_underlying{.*}"
|
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.
2015-06-26 19:27:45 +02:00
|
|
|
gdb_test "print EE" [format $invalid_print "EE"]
|
|
|
|
gdb_test "ptype EE" [format $ptypefmt "EE"]
|
|
|
|
gdb_test "print uu" "= {.*}"
|
|
|
|
gdb_test "ptype uu" "type = union UU {.*}"
|
|
|
|
gdb_test "print UU" [format $invalid_print "UU"]
|
|
|
|
gdb_test "ptype UU" [format $ptypefmt "UU"]
|
|
|
|
|
|
|
|
# These tests exercise lookup of symbols using the "quick fns" API.
|
|
|
|
# Each of them is in a separate CU as once its CU is expanded,
|
|
|
|
# we're no longer using the quick fns API.
|
|
|
|
gdb_test "print E2" "= a2"
|
2015-07-30 23:20:01 +02:00
|
|
|
gdb_test "ptype E2" "type = enum E2 $opt_underlying{.*}"
|
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.
2015-06-26 19:27:45 +02:00
|
|
|
gdb_test "print S2" "= {<No data fields>}"
|
|
|
|
gdb_test "ptype S2" "type = struct S2 {.*}"
|
|
|
|
gdb_test "print U2" "= {.*}"
|
|
|
|
gdb_test "ptype U2" "type = union U2 {.*}"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# First test expressions when there is no context.
|
|
|
|
with_test_prefix "before start" {
|
|
|
|
do_global_tests c++
|
|
|
|
do_global_tests c
|
|
|
|
}
|
|
|
|
|
|
|
|
# Run to main and test again.
|
|
|
|
if {![runto_main]} {
|
|
|
|
perror "couldn't run to main"
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
with_test_prefix "in main" {
|
|
|
|
do_global_tests c++
|
|
|
|
do_global_tests c
|
|
|
|
}
|
|
|
|
|
|
|
|
# Run to C::f and test again.
|
|
|
|
gdb_breakpoint "C::f"
|
|
|
|
gdb_continue_to_breakpoint "continue to C::f"
|
|
|
|
with_test_prefix "in C::f" {
|
|
|
|
do_global_tests c++
|
|
|
|
do_global_tests c
|
|
|
|
}
|
|
|
|
|
|
|
|
# Another hard-to-guess-the-users-intent bug...
|
|
|
|
# It would be really nice if we could query the user!
|
|
|
|
with_test_prefix "global collision" {
|
|
|
|
gdb_test_no_output "set language c++"
|
|
|
|
setup_kfail "c++/16463" "*-*-*"
|
|
|
|
gdb_test "print global" "= 3"
|
|
|
|
|
|
|
|
# ... with a simple workaround:
|
|
|
|
gdb_test "print ::global" "= 3"
|
|
|
|
}
|