From: David Carlton <carlton@math.stanford.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: Demangle partial symbols and save memory too
Date: Mon, 27 Jan 2003 18:53:00 -0000 [thread overview]
Message-ID: <ro1u1fuqv9s.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <20030126222808.GA18132@nevyn.them.org>
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
next prev parent reply other threads:[~2003-01-27 18:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-26 22:27 Daniel Jacobowitz
2003-01-27 1:54 ` Paul N. Hilfinger
2003-01-27 2:02 ` Daniel Jacobowitz
2003-01-27 18:53 ` David Carlton [this message]
2003-01-27 19:00 ` Daniel Jacobowitz
2003-01-27 19:10 ` David Carlton
2003-01-27 21:21 ` Andrew Cagney
2003-01-27 22:09 ` David Carlton
2003-01-27 22:17 ` Andreas Schwab
2003-01-27 22:24 ` David Carlton
2003-01-27 23:17 ` Andrew Cagney
2003-01-28 23:57 ` Jim Blandy
2003-01-30 1:16 ` Daniel Jacobowitz
2003-02-04 18:07 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1u1fuqv9s.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox