gdb and binutils branch master updated. ba715d7fe49c8a59660fbd571b935b29eb7cfbdb

[jkratoch at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  ba715d7fe49c8a59660fbd571b935b29eb7cfbdb (commit)
      from  53df40a43c968f4d97754226d62775d1fe665459 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ba715d7fe49c8a59660fbd571b935b29eb7cfbdb

commit ba715d7fe49c8a59660fbd571b935b29eb7cfbdb
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Thu Dec 4 08:26:26 2014 +0100

    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.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog |    7 +++++++
 gdb/block.c   |   25 +++++++++++++++++++++++++
 gdb/block.h   |    8 ++++++++
 gdb/symtab.c  |    4 +++-
 4 files changed, 43 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
gdb and binutils