This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Removal of demangled names from partial symbols
- To: "Peter.Schauer" <Peter dot Schauer at Regent dot E-Technik dot TU-Muenchen dot DE>
- Subject: Re: Removal of demangled names from partial symbols
- From: Daniel Berlin <dberlin at cygnus dot com>
- Date: Mon, 4 Dec 2000 14:13:02 -0800 (PST)
- cc: gdb at sources dot redhat dot com, gdb-patches at sources dot redhat dot com
On Mon, 4 Dec 2000, Peter.Schauer wrote:
> : Why do we not do a lookup_minimal_symbol in
> : a new function, add_psymbol_and_dem_name_to_list, on the mangled name,
> : and if we get back a symbol, use the demangled name from that,
> : otherwise, demangle it.
>
> For some symbol formats (e.g. a.out) the linkage and debugging symbols are
> intermixed. By the time you want to record a partial symbol, the minimal
> symbol might have not been seen yet. Or the minimal symbol has been seen,
> but the minimal symbols are not yet installed, so lookup_minimal_symbol
> will fail.
>
So i could just use the mapping structure i describe below, and have both
SYMBOL_INIT_DEMANGLED_NAME, et al (IE all the ways we init the demangled
name) attempt to look up the mangled name in it to see if we've demangled
it before. Then it wouldn't matter what order this happened it.
> You might be able to work around this by going over all psymbols and fill
> in the demangled name via lookup_minimal_symbol _after_ the minimal symbols
> are installed, but I am not yet convinced that you don't have to pay your
> price on slower systems. After all, 5 secs to 6 secs is a 20% slowdown.
Except we already pay the price on ELF, where unless you've stripped it,
your minsyms contain just about all the symbols used in the program.
It's also an issue of saving ~50% of the memory we use now (Remember, the
slowdown comes from the bcaching, which would also not be necessary with
the mapping structure), and making lookups dramatically faster.
Without the bcaching, profiling shows all the time being used because
the lookup_minimal symbol, as you would expect.
Further analysis shows msymbol_hash_iw function isn't very good, and even
if it was perfect we have 379 buckets, total, per object file, so on 100000
symbols, most concentrated in one object file (the main program in this
case, which has 100 meg of debug info, and 100k symbols) ,we have chains
with an average length of 286. If we assume we have to search half those,
we are doing 143 strcmps to find the minimal symbol to get the demangled
name out of. The ternary search tree i propose would require the equivalent of one strcmp to find the
name.
Users i've talked to are more annoyed that once gdb gets going, it takes
for ever to do anything, because the symbol lookups take so long, than
they are that gdb takes 3 minutes vs 3 minutes, 30 seconds, to start up.
Let me finish integrating the mapping structure (I have the ternary
search tree in libiberty, in case others wanted to use it), and do some
tests to see how much faster it is.
--Dan