-
- Downloads
"README.md" did not exist on "cd102ea65916929da4ac2e046fc7c370aa9d5449"
[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.
Loading
Please register or sign in to comment