Re: [PATCH] Fix compute_bucket_count

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jul 03, 2006 at 03:43:52PM +0930, Alan Modra wrote:
> > 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?

Well, if we want to use a bigger number, we certainly can, not sure if
we want some multiply of (hashcodesp - hashcodes) or just add some constant
(i.e. say (hashcodesp - hashcodes) * 1.1 < elf_buckets[i + 1] or
(hashcodesp - hashcodes) + 20 < elf_buckets[i + 1]).  What I'm just trying
to say that the heuristics should have nothing to do with dynsymcount,
it really shouldn't care how many special symbols you have in .dynsym that
are not added to the hash table.

But if you want, we can keep it as is and only change the heuristics
for the new .gnu.hash section.

	Jakub