From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21591 invoked by alias); 18 Feb 2004 22:45:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21575 invoked from network); 18 Feb 2004 22:45:12 -0000 Received: from unknown (HELO demos.bsdclusters.com) (69.55.225.36) by sources.redhat.com with SMTP; 18 Feb 2004 22:45:12 -0000 Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id i1IMiumO022435; Wed, 18 Feb 2004 14:44:56 -0800 (PST) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id i1IMiu1I022428; Wed, 18 Feb 2004 14:44:56 -0800 (PST) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Wed, 18 Feb 2004 22:45:00 -0000 From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: David Carlton cc: gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 In-Reply-To: Message-ID: <20040218143915.D18075@demos.bsdclusters.com> References: <20040218210927.GA16641@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-02/txt/msg00234.txt.bz2 About a year ago our tools person added symbol-caching to our in-house GDB tree. He happened to use an STL map, although there are certainly more C-compliant ways. Prior to this change, developers had to use pointer arithmetic in their macros to avoid repeated lookups or their macros would run too SLOW. Would symbol-caching be something that would make sense for mainline GDB? -Kip On Wed, 18 Feb 2004, David Carlton wrote: > On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz 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 >