Re: [rfa:symtab] SYMBOL_LOCATION_FUNCS -> SYMBOL_OPS

[Daniel Jacobowitz <drow@mvista.com>]

On Sat, Nov 08, 2003 at 03:35:57PM -0500, Andrew Cagney wrote:
> Hello,
> 
> This patch generalizes the per-symbol location_funcs, replacing them 
> with a symbol_ops vector (the contents are unchanged).  The patch 
> doesn't change the size of the symbol.
> 
> As the comment hints:
> 
> +  /* NOTE: cagney/2003-11-02: The fields "aclass" and "ops" contain
> +     overlaping information.  Since GDB has only a small finite number
> +     of symbol classes it should be possible to merge the two fields
> +     into a single ops-table "index".  Each entry providing both the
> +     "ops" and the "aclass" values.  Doing that would shave 32 bits
> +     off every symbol.  */
> 
> The patch sets us up for a more significant change - merge "ops" and 
> "aclass" - and hence eliminates 32 bits (or 20%) of each symbol.  I 
> should note that right now the details of the merge are "left as an 
> exercise for the reader".

FWIW, this patch looks good to me.  I only have two questions.  One is
with the generalized name - do you expect anything besides the location
(the aclass really is a part of the location, I think) to be handled by
these ops?  I'm not sure what else there is, so it's just an idle
thought.

And, I think I see where you're going with the index idea, but since it
wasn't obvious until the second time through: the index could take up
to ten bits, replacing the address class, and thereby eliminating the
ops pointer.  That's where the 32 bits comes from, not from eliminating
aclass.  This costs a table lookup every time you want to get at the
aclass or ops, but that's probably OK.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer