Using a cc1 executable build with gcc 7.4.0 and CFLAGS/CXXFLAGS="-O0 -g", I see a significant performance regression loading the executable comparing tip of 8.2/8.3 branches, both with and without -readnow. I've bisected this to: ... commit 9325300dc283ece6bf6305b912f53114c0895114 Author: Tom de Vries <tdevries@suse.de> Date: Fri Nov 9 11:54:04 2018 +0100 [gdb/symtab] Fix language of duplicate static minimal symbol ...
before: ... $ time.sh ./install/bin/gdb -readnow -batch ./cc1 maxmem: 1260660 real: 15.40 user: 13.92 system: 1.47 ... after: ... $ time.sh ./install/bin/gdb -readnow -batch ./cc1 maxmem: 1260708 real: 24.76 user: 19.07 system: 5.68 ...
patch submitted: https://sourceware.org/ml/gdb-patches/2019-05/msg00293.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e99f9db0f5211455ca4256e8db9d9081967d255e commit e99f9db0f5211455ca4256e8db9d9081967d255e Author: Tom de Vries <tdevries@suse.de> Date: Mon Jun 10 20:05:04 2019 +0200 [gdb/symtab] Fix symbol loading performance regression The commit "[gdb/symtab] Fix language of duplicate static minimal symbol" introduces a performance regression, when loading a cc1 executable build with -O0 -g and gcc 7.4.0. The performance regression, measured in 'real' time is about 175%. The slower execution comes from the fact that the fix in symbol_set_names makes the call to symbol_find_demangled_name unconditional. Fix this by reverting the commit, and redoing the fix as follows. Recapturing the original problem, the first time symbol_set_names is called with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is not present in the per_bfd->demangled_names_hash hash table, so symbol_find_demangled_name is called to demangle the name, after which the mangled/demangled pair is added to the hashtable. The call to symbol_find_demangled_name also sets gsymbol.language to lang_cplus. The second time symbol_set_names is called with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is present in the hash table, so the demangled name from the hash table is used. However, the language of the symbol remains lang_auto. Fix this by adding a field language in struct demangled_name_entry, and using the field in symbol_set_names to set the language of gsymbol, if necessary. Tested on x86_64-linux. gdb/ChangeLog: 2019-06-10 Tom de Vries <tdevries@suse.de> PR symtab/24545 * symtab.c (struct demangled_name_entry): Add language field. (symbol_set_names): Revert "[gdb/symtab] Fix language of duplicate static minimal symbol". Set and use language field.
Patch committed, marking resolved-fixed.
The gdb-8.3-branch branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4de026046bfc49013f9089aaf31bc3200adb5c77 commit 4de026046bfc49013f9089aaf31bc3200adb5c77 Author: Tom de Vries <tdevries@suse.de> Date: Sun Jul 21 20:01:35 2019 +0200 [gdb/symtab] Fix symbol loading performance regression [ Backport of master commit e99f9db0f5. ] The commit "[gdb/symtab] Fix language of duplicate static minimal symbol" introduces a performance regression, when loading a cc1 executable build with -O0 -g and gcc 7.4.0. The performance regression, measured in 'real' time is about 175%. The slower execution comes from the fact that the fix in symbol_set_names makes the call to symbol_find_demangled_name unconditional. Fix this by reverting the commit, and redoing the fix as follows. Recapturing the original problem, the first time symbol_set_names is called with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is not present in the per_bfd->demangled_names_hash hash table, so symbol_find_demangled_name is called to demangle the name, after which the mangled/demangled pair is added to the hashtable. The call to symbol_find_demangled_name also sets gsymbol.language to lang_cplus. The second time symbol_set_names is called with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is present in the hash table, so the demangled name from the hash table is used. However, the language of the symbol remains lang_auto. Fix this by adding a field language in struct demangled_name_entry, and using the field in symbol_set_names to set the language of gsymbol, if necessary. Tested on x86_64-linux. gdb/ChangeLog: 2019-06-10 Tom de Vries <tdevries@suse.de> PR symtab/24545 * symtab.c (struct demangled_name_entry): Add language field. (symbol_set_names): Revert "[gdb/symtab] Fix language of duplicate static minimal symbol". Set and use language field.