[Bug symtab/16994] New: performance issue looking up static symbols (e.g. int, int64 typedef).

["dje at google dot com" <sourceware-bugzilla at sourceware dot org>]

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.