This is the mail archive of the gdb@sources.redhat.com 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]

Re: Removal of demangled names from partial symbols





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

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