This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Fix compute_bucket_count
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 3 Jul 2006 15:43:52 +0930
- Subject: Re: [PATCH] Fix compute_bucket_count
- References: <20060623155502.GT3823@sunsite.mff.cuni.cz>
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