From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1317 invoked by alias); 27 Jan 2003 19:00:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1297 invoked from network); 27 Jan 2003 19:00:45 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 27 Jan 2003 19:00:45 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18dGNq-0003dB-00 for ; Mon, 27 Jan 2003 15:01:35 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18dEVJ-0002xD-00 for ; Mon, 27 Jan 2003 14:01:09 -0500 Date: Mon, 27 Jan 2003 19:00:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFC: Demangle partial symbols and save memory too Message-ID: <20030127190109.GA11294@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030126222808.GA18132@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00733.txt.bz2 On Mon, Jan 27, 2003 at 10:53:35AM -0800, David Carlton wrote: > On Sun, 26 Jan 2003 17:28:08 -0500, Daniel Jacobowitz said: > > > So I figured, the demangler is expensive (even after my unreviewed > > GCC patch to kill the memory leaks in it). So why not avoid it? > > Demangle the names only once, or at least only once per objfile. > > Hash them based on the mangled name. > > Thanks for doing this; I really appreciate it. It will make my life > easier. > > > + > > +/* Set both the mangled and demangled (if any) names for GSYMBOL based on > > + NAME and LEN. The hash table corresponding to OBJFILE is used, and the > > + memory comes from that objfile's symbol_obstack. NAME is copied, so the > > + pointer can be discarded after calling this function. */ > > + > > +void > > +symbol_set_names (struct general_symbol_info *gsymbol, > > + char *name, int len, struct objfile *objfile) > > Personally, I'd prefer that name be const char *. And, for that > matter, I'd rather have the demangled name member of struct > general_symbol_info be a const char *: it will be shared, so changing > it really would be bad. But that's really a separate issue; I'll > submit a patch for that one myself later. Thanks for reminding me; I'll fix the first const char *. You'll notice I fixed the ugly places I was modifying it already, from our last discussion. > > > +{ > > + char **slot; > > + char *tmpname; > > + > > + if (objfile->demangled_names_hash == NULL) > > + create_demangled_names_hash (objfile); > > + > > + if (name[len] != 0) > > + { > > + tmpname = alloca (len + 1); > > + memcpy (tmpname, name, len); > > + tmpname[len] = 0; > > + } > > + else > > + tmpname = name; > > Well, I like this better than the last time I saw it, but I'll still > give you a hard time. :-) You're assuming that name[len] is readable, > for the sake of an optimization that doesn't seem to me to have much > of a benefit (it could even be a pessimization if a high enough > proportion of names have name[len] nonzero, though that seems unlikely > to me). On the other hand, it does seem silly to copy the name if you > don't have to; a matter of taste, I suppose. It's simple: - stabs, name[len] will be readable but generally non-zero. - everything else, name[len] will be zero. Hmm, think it would be better to push the alloca out into the stabs callers? Maybe that would work. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer