This is the mail archive of the gdb-patches@sourceware.org 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]

Re: [3/10] introduce psymtab users


On Thu, 26 Apr 2012 20:38:12 +0200, Tom Tromey wrote:
> >> @@ -760,6 +769,11 @@ lookup_partial_symbol (struct partial_symtab
> >> *pst, const char *name,
> >> static struct symtab *
> >> psymtab_to_symtab (struct partial_symtab *pst)
> >> {
> >> +  /* If it is a shared psymtab, find an unshared psymtab that includes
> >> +     it.  Any such psymtab will do.  */
> >> +  while (pst->users != NULL)
> >> +    pst = pst->users[0];
> 
> Jan> Currently GDB already has a problem that if it needs to expand
> Jan> symtab A to get symbol X it already expands also symtabs B, C and
> Jan> D, all of them pretty big for C++.
> 
> Jan> With such random choosing of a symtab for expansion this multi-expand
> Jan> performance hit may get even worse for big C++ programs.
> 
> Jan> (Not sure if you do not already plan some more general fix for that.)
> 
> Someday I would like to implement my lazy CU expansion ideas.
> Well, unless we think of something better.  And if we think they'll help
> enough; first one of us should redo the performance comparisons.
> 
> In the short term, though, I don't think this makes things any worse.
> My reasoning is that in the uncompressed DWARF, gdb would read the first
> matching CU.  With the compressed DWARF, gdb still does exactly this,
> only it reads the CU and the included PUs.

I had on my mind a case where it can make the performance worse but I see now
it cannot.

If PST is not yet expanded it means very every pst->users[i] element is also
not expanded, right?


Thanks,
Jan


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