Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Change cplus_specific to an alocated struct
Date: Tue, 08 Jun 2010 17:02:00 -0000	[thread overview]
Message-ID: <m34ohdlap4.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4BFD4230.3030600@redhat.com> (sami wagiaalla's message of "Wed,	26 May 2010 11:45:52 -0400")

>>>>> "Sami" == sami wagiaalla <swagiaal@redhat.com> writes:

Sami> I plan to expand the cplus_specific struct to store template
Sami> information needed, of course, only for C++. Tom suggested that I move
Sami> the substruct out of struct general_symbol_info and change its
Sami> reference to a pointer to be assigned to the struct if allocated.

Sami> Thoughts ?

I think the idea is fine.

Sami>  char *
Sami>  ada_decode_symbol (const struct general_symbol_info *gsymbol)
Sami>  {
Sami> -  char **resultp =
Sami> -    (char **) &gsymbol->language_specific.cplus_specific.demangled_name;
Sami> -  if (*resultp == NULL)
Sami> +  char *result = symbol_get_cplus_demangled_name (gsymbol);

I don't think this change is correct -- but FWIW I don't think the
existing code is correct, either.

The code is written this way because this function caches the demangled
name in the cplus_specific struct.  Your change removes this caching.

However, this takes a general_symbol_info and so, presumably, can be
used for partial symbols.  But, modifying a partial symbol is a no-no,
because they are stored in a bcache.

All this reminds me -- you should look at bcache utilization and memory
use before and after your changes to make sure we aren't hitting a
memory use regression here.  There is some command that will show you
bcache statistics, though I forget what it is offhand.

Sami> +char *
Sami> +symbol_get_cplus_demangled_name (const struct general_symbol_info *gsymbol)
Sami> +{
Sami> +  if (gsymbol->language_specific.cplus_specific != NULL)
Sami> +    return gsymbol->language_specific.cplus_specific->demangled_name;
Sami> +
Sami> +  return NULL;
Sami> +}

Perhaps we should have different types of structs in the
language_specific union, and have functions like this examine the
language field.

It seems to me that soon we're going to want to add a bunch of
C++-specific fields, and we don't want to unnecessarily penalize the
other languages with our baggage.

If you were planning that for a follow-on patch, that is fine -- but
also the sort of thing that it is handy to note in your submissions.

Sami> +/* Initialize the cplus_specific structure.  'cplus_specific' is intended to
Sami> +   be allocated lazily.  So this should only be called if the structure is
Sami> +   needed.  */
Sami> +static void
Sami> +symbol_init_cplus_specific (struct general_symbol_info *gsymbol,
Sami> +                           struct objfile *objfile)

Initializing lazily is usually good, but it breaks the bcache.
However perhaps this can be fixed by having the partial symbol code
force the issue.

Tom


  parent reply	other threads:[~2010-06-08 17:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26 16:05 sami wagiaalla
2010-05-26 16:55 ` sami wagiaalla
2010-06-08 17:02 ` Tom Tromey [this message]
2010-06-14 19:29   ` sami wagiaalla
2010-06-15 22:56     ` Tom Tromey
2010-07-12 18:03       ` [patch 1/3] " sami wagiaalla
2010-07-13 17:16         ` Tom Tromey
2010-07-16 14:15           ` sami wagiaalla
2010-07-16 15:24             ` Tom Tromey
2010-07-12 18:06       ` [patch 2/3] " sami wagiaalla
2010-07-13 17:24         ` Tom Tromey
2010-07-16 14:15           ` sami wagiaalla
2010-07-12 18:08       ` [patch 3/3] " sami wagiaalla
2010-07-13 17:38         ` Tom Tromey
2010-07-16 14:15           ` sami wagiaalla
2010-07-16 15:29             ` Tom Tromey

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=m34ohdlap4.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=swagiaal@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