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]
Other format: [Raw text]

Re: Huge slowdown since 6.0


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.

David Carlton
carlton@kealia.com


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