Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME

[Daniel Jacobowitz <drow@false.org>]

On Mon, Feb 16, 2004 at 04:48:57PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > After this patch and my others from today there are no direct
>  > assignments to the symbol name. In addition to the cleanup value, I'm
>  > testing an approach which would change the storage of symbol names,
>  > which prompted me to do this.  
> 
> can you elaborate on where you are going?

Sure.  I'm not sure if it's actually going to end up this way, since
I'm thinking it wasn't a great idea and it has some truly gross bits I
haven't figured out what to do with yet - it was just a hack job last
weekend.  But here's what my current tree does.

The C++ demangled name pointer in lang_specific is removed.  The name
pointer becomes a union, and a flag bit (there's about a byte's worth
of empty space in general_symbol_info) is added.  They look like this:

  /* The name(s) of this symbol.  Storage for the names will be generally
     be allocated on the objfile_obstack for the associated objfile, through
     a hash table or bcache.  */

  union {
    /* If the flag HAS_DEMANGLED_NAMES (below) is clear, this points to
       the name of the symbol.  */
    char *name;

    /* If HAS_DEMANGLED_NAMES is set, this points to a structure describing
       this symbol's names.  The structure may be shared.  */
    struct symbol_name_info *names;
  } name_union;

  /* A flag indicating which member of NAME_UNION is in use.  */
  unsigned int has_demangled_names : 1;

struct symbol_name_info
{
  /* ADD MORE COMMENTS */
  char *linkage_name;
  char *demangled_name;
  unsigned int has_full_demangled_name : 1;
  unsigned int linkage_len : 31;
};

I store several different pieces of data here.  ->linkage_name +
->linkage_len points to the result of demangling linkage_name without
DMGL_PARAMS: that is, without any function arguments or return type
information. If HAS_FULL_DEMANGLED_NAME, then demangled_name points to
the normal (full) demangled name.  Otherwise it points to the
appropriate obstack to store the demangled name on.

Then I convert the symbol readers to only use the short demangled name,
which I call SYMBOL_DEMANGLED_SEARCH_NAME.  SYMBOL_DEMANGLED_NAME fills
in lazily when needed.  Some memory is saved directly because the
symbol_name_info structure is shared between partial, full, and minimal
symbols; removing the demangled_name pointer leaves net savings of a
(very roughly) a word per C++ symbol.  Symbols which do not have a
demangled name no longer have space allocated for one, so there is also
a savings for straight C code.

I wanted the without-arguments names available because, in 99% of
cases, they are all we need.  Less memory, less time in the demangler,
et cetera.

This whole project grew out of profiling results for a large dwarf2 C
application, which shows a similar profile to C++ : the biggest hot
spot in startup time today is compare_psymbols.  My hope is to do that
using strcmp, or something even more efficient, instead of ~6,000,000
calls to strcmp_iw.  I started working on the symbol name cleanups
first, but I think saving the hash code in the symbol_name_info might
be even more effective.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer