Re: [PATCH] Fix compute_bucket_count

[Alan Modra <amodra@bigpond.net.au>]

On Fri, Jun 23, 2006 at 05:55:02PM +0200, Jakub Jelinek wrote:
> I believe this hasn't been updated since (most of) 64-bit targets
> started using 4 byte .hash sh_entsize (as required by ELF).
> Certainly max = (2 + nsyms) * (bed->s->arch_size / 8);
> looks very much like an attempt to compute the size of the .hash
> section except the nbuckets part.  But
> 1) on most 64-bit targets .hash entsize is not 8

Of course using the "wrong" sizes just tweaks the weighting given to
short chains vs. overall table size.  Still, we may as well be using the
same algorithm for 64-bit vs. 32-bit.  Changing (bed->s->arch_size / 8)
to bed->s->sizeof_hash_entry is OK to commit.

> 2) the chains part of .hash section is really dynsymcount entries large
>    (corresponds 1:1 to .dymsym entries), while nsyms can be smaller number
>    (STT_SECTION symbols, symbol 0)
> On the other side, when not optimizing, compute_bucket_count was looking
> at dynsymcount, but in that case the interesting number really is the number
> of dynamic symbols that are entered into the .hash table.

I'm not so sure about this change, which affects both 32-bit and
64-bit.  If I've analysed the change correctly, it will tend to result
in smaller hash tables at the expense of possibly longer chains, in both
the optimising and non-optimising cases.  Do we really want that?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre