Re: RFC: Demangle partial symbols and save memory too

Daniel Jacobowitz
2003-01-27T19:00:45Z

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