diff options
author | Jan Kratochvil <jan.kratochvil@redhat.com> | 2014-12-04 08:26:26 +0100 |
---|---|---|
committer | Jan Kratochvil <jan.kratochvil@redhat.com> | 2014-12-04 08:26:26 +0100 |
commit | ba715d7fe49c8a59660fbd571b935b29eb7cfbdb (patch) | |
tree | 0c940c00fdc8a993b83c43454595c2904ed986e8 /gdb/block.h | |
parent | 53df40a43c968f4d97754226d62775d1fe665459 (diff) | |
download | fsf-binutils-gdb-ba715d7fe49c8a59660fbd571b935b29eb7cfbdb.zip fsf-binutils-gdb-ba715d7fe49c8a59660fbd571b935b29eb7cfbdb.tar.gz fsf-binutils-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.h')
-rw-r--r-- | gdb/block.h | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/gdb/block.h b/gdb/block.h index bd358d6..409a5c7 100644 --- a/gdb/block.h +++ b/gdb/block.h @@ -276,6 +276,14 @@ extern struct symbol *block_lookup_symbol (const struct block *block, const char *name, const domain_enum domain); +/* Search BLOCK for symbol NAME in DOMAIN but only in primary symbol table of + BLOCK. BLOCK must be STATIC_BLOCK or GLOBAL_BLOCK. Function is useful if + one iterates all global/static blocks of an objfile. */ + +extern struct symbol *block_lookup_symbol_primary (const struct block *block, + const char *name, + const domain_enum domain); + /* Macro to loop through all symbols in BLOCK, in no particular order. ITER helps keep track of the iteration, and must be a struct block_iterator. SYM points to the current symbol. */ |