This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Why do not demangle at link time?

For a huge C++ binaries, it's quite typical to have a bottleneck in demangling while
loading symbols; I've seen >30% of time spent in d_xxx and friends, for example:

    12.19%  gdb      gdb                   [.] d_print_comp_inner
    10.11%  gdb      gdb                   [.] cp_find_first_component_aux
     6.21%  gdb      gdb                   [.] minimal_symbol_reader::install
     5.11%  gdb      gdb                   [.] htab_hash_string
     4.00%  gdb      gdb                   [.] d_print_comp
     3.56%  gdb      gdb                   [.] d_count_templates_scopes
     2.66%  gdb          [.] __strcmp_sse2_unaligned
     2.58%  gdb          [.] _int_malloc
     1.86%  gdb      gdb                   [.] cp_search_name_hash
     1.69%  gdb          [.] strlen
     1.65%  gdb      gdb                   [.] d_name
     1.52%  gdb      gdb                   [.] cplus_demangle_type
     1.52%  gdb      gdb                   [.] compare_minimal_symbols
     1.51%  gdb      gdb                   [.] htab_find_slot_with_hash
     1.31%  gdb      gdb                   [.] d_make_comp

(observed on Chrome binary with .gdb_index embedded at link time). OK, .gdb_index
was designed to load symbols faster, and both gold and lld can emit it when linking;
so why do not (optionally) offload all demangling to linkers and extend .gdb_index
to add a kind of mapping from mangled to demangled symbol names?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]