Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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