aboutsummaryrefslogtreecommitdiff
path: root/gdb/block.c
diff options
context:
space:
mode:
authorJan Kratochvil <jan.kratochvil@redhat.com>2014-12-04 08:26:26 +0100
committerJan Kratochvil <jan.kratochvil@redhat.com>2014-12-04 08:26:26 +0100
commitba715d7fe49c8a59660fbd571b935b29eb7cfbdb (patch)
tree0c940c00fdc8a993b83c43454595c2904ed986e8 /gdb/block.c
parent53df40a43c968f4d97754226d62775d1fe665459 (diff)
downloadgdb-ba715d7fe49c8a59660fbd571b935b29eb7cfbdb.zip
gdb-ba715d7fe49c8a59660fbd571b935b29eb7cfbdb.tar.gz
gdb-ba715d7fe49c8a59660fbd571b935b29eb7cfbdb.tar.bz2
Accelerate lookup_symbol_aux_objfile 85x
During debugging I get 10-30 seconds for a response to simple commands like: (gdb) print vectorvar.size() With this patch the performance gets to 1-2 seconds which is somehow acceptable. The problem is that dwarf2_gdb_index_functions.lookup_symbol (quick_symbol_functions::lookup_symbol) may return (and returns) NULL even for symbols which are present in .gdb_index but which can be found in already expanded symtab. But searching in the already expanded symtabs is just too slow when there are 400000+ expanded symtabs. There would be needed some single global hash table for each objfile so that one does not have to iterate all symtabs. Which .gdb_index could perfectly serve for, just its lookup_symbol() would need to return authoritative yes/no answers. Even after such fix these two simple patches are useful for example for non-.gdb_index files. One can reproduce the slugging interactive GDB performance with: #include <string> using namespace std; string var; class C { public: void m() {} }; int main() { C c; c.m(); return 0; } g++ -o slow slow.C -Wall -g $(pkg-config --libs gtkmm-3.0) gdb ./slow -ex 'b C::m' -ex 'maintenance set per-command space' -ex 'maintenance set per-command symtab' -ex 'maintenance set per-command time' -ex r [...] (gdb) p <tab><tab> Display all 183904 possibilities? (y or n) n (gdb) p/r var $1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3a4db073d8 <std::string::_Rep::_S_empty_rep_storage+24> ""}} Command execution time: 20.023000 (cpu), 20.118665 (wall) ^^^^^^^^^ Space used: 927997952 (+0 for this command) Without DWZ there are X global blocks for X primary symtabs for X CUs of objfile. With DWZ there are X+Y global blocks for X+Y primary symtabs for X+Y CUs where Y are 'DW_TAG_partial_unit's. For 'DW_TAG_partial_unit's (Ys) their blockvector is usually empty. But not always, I have found there typedef symbols, there can IMO be optimized-out static variables etc. Neither of the patches should cause any visible behavior change. gdb/ChangeLog 2014-12-04 Jan Kratochvil <jan.kratochvil@redhat.com> * block.c (block_lookup_symbol_primary): New function. * block.h (block_lookup_symbol_primary): New declaration. * symtab.c (lookup_symbol_in_objfile_symtabs): Assert BLOCK_INDEX. Call block_lookup_symbol_primary.
Diffstat (limited to 'gdb/block.c')
-rw-r--r--gdb/block.c25
1 files changed, 25 insertions, 0 deletions
diff --git a/gdb/block.c b/gdb/block.c
index 597d143..e791c73 100644
--- a/gdb/block.c
+++ b/gdb/block.c
@@ -746,3 +746,28 @@ block_lookup_symbol (const struct block *block, const char *name,
return (sym_found); /* Will be NULL if not found. */
}
}
+
+/* See block.h. */
+
+struct symbol *
+block_lookup_symbol_primary (const struct block *block, const char *name,
+ const domain_enum domain)
+{
+ struct symbol *sym;
+ struct dict_iterator dict_iter;
+
+ /* Verify BLOCK is STATIC_BLOCK or GLOBAL_BLOCK. */
+ gdb_assert (BLOCK_SUPERBLOCK (block) == NULL
+ || BLOCK_SUPERBLOCK (BLOCK_SUPERBLOCK (block)) == NULL);
+
+ 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;
+ }
+
+ return NULL;
+}