Re: RFC: Demangle partial symbols and save memory too

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jan 27, 2003 at 10:53:35AM -0800, David Carlton wrote:
> On Sun, 26 Jan 2003 17:28:08 -0500, Daniel Jacobowitz <drow@mvista.com> 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