Re: RFC: Demangle partial symbols and save memory too

David Carlton
2003-01-27T18:53:41Z

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.

> +{
> + 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.

David Carlton
carlton@math.stanford.edu