From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34424 invoked by alias); 26 Jun 2015 18:43:16 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 34395 invoked by uid 55); 26 Jun 2015 18:43:16 -0000 From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug c++/16253] Cannot print an enum var with the same name as tag Date: Fri, 26 Jun 2015 18:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: keiths at redhat dot com X-Bugzilla-Target-Milestone: 7.8 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q2/txt/msg00476.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16253 --- Comment #18 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Keith Seitz : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ee93cd5e1e61e5739a1a44e0d1d166ae09d04dc2 commit ee93cd5e1e61e5739a1a44e0d1d166ae09d04dc2 Author: Keith Seitz Date: Fri Jun 26 10:27:45 2015 -0700 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. -- You are receiving this mail because: You are on the CC list for the bug.