public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "dje at google dot com" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-16994-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2014-05-28 17:18 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-05-28 17:18 dje at google dot com [this message] 2014-05-29 20:37 ` [Bug symtab/16994] " dje at google dot com 2014-05-29 23:32 ` dje at google dot com 2014-12-07 19:20 ` xdje42 at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-16994-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).