From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 530 invoked by alias); 28 May 2014 17:18:56 -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 496 invoked by uid 48); 28 May 2014 17:18:54 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/16994] New: performance issue looking up static symbols (e.g. int, int64 typedef). Date: Wed, 28 May 2014 17:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: 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/msg00286.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug ID: 16994 Summary: performance issue looking up static symbols (e.g. int, int64 typedef). Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: symtab Assignee: unassigned at sourceware dot org Reporter: dje at google dot com This pr is to address the performance issue gdb has when looking up symbols in STATIC_BLOCK. gdb will iterate over all CUs looking for static symbols as a last resort, but this introduces performance issues that one might not easily predict. See pr 16253 for an example of accidentally introducing such a perf regression. E.g., to perform "info fun ^foo::(anonymous namespace)", inspect_type will first look in STRUCT_DOMAIN for a symbol, and if that fails look in VAR_DOMAIN. However, the attributes in .gdb_index don't distinguish STRUCT_DOMAIN types from VAR_DOMAIN types. During symbol lookup, dw2_symtab_iter_next will return every entry that exists for int64 (and there can be thousands), gdb will expand the CU, look for the symbol, not get a match because it's in the wrong domain, and then try the next. This will cause gdb to expand every CU. Then when this lookup fails inspect_type will try VAR_DOMAIN, assuming the user was willing to wait that long ... In this case the "last resort" lookup is killing us, we want the lookup in STRUCT_DOMAIN to fail fast. ref: symtab.c:lookup_symbol_aux /* Now search all static file-level symbols. Not strictly correct, but more useful than an error. */ =>return lookup_static_symbol_aux (name, domain); "more useful than an error" is ignoring the *massive* performance hit (and by massive I mean effectively doing a -readnow in a program with a 2G fission .dwp file). There is also the issue of looking up base types like "int". It can be slower than necessary too, for similar reasons. Plus if some type isn't defined in the CU (say double) then we want gdb to look in the default set (provided by the architecture) after it has looked in the current CU and before it does this last resort attempt of looking through all CUs. One reason for doing this is that if the next CU to be looked in happened to be compiled with -fshort-double gdb will give the wrong answer. -- You are receiving this mail because: You are on the CC list for the bug.