From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15800 invoked by alias); 28 May 2014 01:51:04 -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 15714 invoked by uid 48); 28 May 2014 01:51:02 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/16253] Cannot print an enum var with the same name as tag Date: Wed, 28 May 2014 01:51: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: dje at google dot com X-Bugzilla-Status: REOPENED 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: bug_status cc resolution 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: 2014-q2/txt/msg00284.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16253 dje at google dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |dje at google dot com Resolution|FIXED |--- --- Comment #7 from dje at google dot com --- Alas the patch introduces a massive perf regression in one of my perf tests. Using my standard monster testcase, doing "info fun ^foo::(anonymous namespace)" goes from about a minute to an untold number of minutes (expected to be in the thousands :-)). .gdb_index has this for int64: [1476052] int64: 2 [static, type] 4 [static, type] 5 [static, type] ... There are 10K such entries. The output of "info fun ..." includes "int64" so cp_canonicalize_string_full ("int64") is called. cp-support.c:inspect_type first tries to look up the symbol in STRUCT_DOMAIN, and then in VAR_DOMAIN. The problem is that there is insufficient info in the index to know a lookup in STRUCT_DOMAIN will fail, so dw2_symtab_iter_next will blindly return every entry in the index, which will cause every CU to be expanded. Later, when we do the lookup in the symtab, the domains won't match (int64 is in VAR_DOMAIN) so the lookup will fail and we'll try the next entry in the index ... Later, inspect_type will try VAR_DOMAIN: if (current_language->la_language == language_cplus) sym = lookup_symbol (name, 0, STRUCT_DOMAIN, 0); if (sym == NULL) sym = lookup_symbol (name, 0, VAR_DOMAIN, NULL); but that's only after gdb has expanded the debug info for 10K CUs. Ugh. One solution is to encode the STRUCT_DOMAIN/VAR_DOMAIN attribute in the index. We should first see what's involved in generating this, and whether gold can. Another solution would be for symbol lookup to stop iterating over every CU looking for static symbols (or at least not do that until the very VERY end). If I'm in CU foo.o I should expect to not get the definition of "static" symbol baz in bar.o. This also ties in with the currently broken lookup of "int": we should search the current CU, then the arch defaults, then maybe as a last resort every CU. The performance cost of these "last resort" lookups on big programs has soured me on doing that by default though. In the case of "info fun ..." where cp_canonicalize_string_full isn't passed a CU (so how can it know which CU to look in for static symbols), we need to start passing it one (and similarly throughout gdb). I'm going to check if there's an existing PR for this perf problem, and open a new one if not. I think this is a blocker for 7.8. -- You are receiving this mail because: You are on the CC list for the bug.