This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Huge slowdown since 6.0
On Wed, Feb 18, 2004 at 01:31:12PM -0800, David Carlton wrote:
> On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz <drow@false.org> said:
>
> > The only reasonable explanation is that the number of global symbols has
> > vastly increased. This appears to be the case. David, the blame appears to
> > be yours, in dwarf2read.c revision 1.120:
>
> > @@ -1519,14 +1556,16 @@ add_partial_symbol (struct partial_die_i
> > /* For C++, these implicitly act as typedefs as well. */
> > add_psymbol_to_list (actual_name, strlen (actual_name),
> > VAR_DOMAIN, LOC_TYPEDEF,
> > - &objfile->static_psymbols,
> > + &objfile->global_psymbols,
> > 0, (CORE_ADDR) 0, cu_language, objfile);
> > }
> > break;
> > case DW_TAG_enumerator:
> > add_psymbol_to_list (actual_name, strlen (actual_name),
> > VAR_DOMAIN, LOC_CONST,
> > - &objfile->static_psymbols,
> > + cu_language == language_cplus
> > + ? &objfile->static_psymbols
> > + : &objfile->global_psymbols,
> > 0, (CORE_ADDR) 0, cu_language, objfile);
> > break;
> > default:
>
> > Could you re-explain the need for this change, please? You said:
>
> > + /* NOTE: carlton/2003-11-10: C++ class symbols shouldn't
> > + really ever be static objects: otherwise, if you try
> > + to, say, break of a class's method and you're in a file
> > + which doesn't mention that class, it won't work unless
> > + the check for all static symbols in lookup_symbol_aux
> > + saves you. See the OtherFileClass tests in
> > + gdb.c++/namespace.exp. */
> > +
>
> > but is that also necessary for enumerators? As things stand, one
> > large enum in a used header can lead to worse-than-linear slowdown
> > of GDB startup for DWARF-2, and a couple megabytes of wasted memory.
>
> Crap. Well, in some sense, enumerators really are global in C++: it's
> illegal to have two different enums in the same scope that have an
> enumerator with the same name. (I'm pretty sure.) So, in the
> mythical future super-groovy-GDB where we coalesce all sorts of
> type-related debug information across files, it would be nice if, in
> the C++ case, enumerators were treated as global (and were coalesced).
>
> Having said that, it should be the case that handling enumerators this
> way is much less important than handling class symbols this way. I
> can't quite envision the consequences of reverting the change for
> enumerators; it will mean that you can't print out enumerators that
> are defined in namespaces and that aren't in the debug info for the
> current source file (if any), but that doesn't sound like too big a
> deal to me.
OK, boot to the head time.
My testcase is in C.
These are all conditionalized on language_cplus.
How can they possibly be to blame? Well, they are. And reverting the
change for enumerators definitely won't do any harm. Take a look at
this, read it two or three times if necessary - it took me about a
dozen:
> > - &objfile->static_psymbols,
> > + cu_language == language_cplus
> > + ? &objfile->static_psymbols
> > + : &objfile->global_psymbols,
If I swap "static" and "global", it reduces GDB startup time by roughly
40% for glibc with debug information, which contains a lot of C
enumerators. I assume that is what you meant to do in the first place?
If so I can recover the speed hit for C for GDB 6.1, and then address
the larger issues with large numbers of global psymbols in HEAD after
we branch.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer