From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15701 invoked by alias); 3 Jul 2006 06:14:02 -0000 Received: (qmail 15687 invoked by uid 22791); 3 Jul 2006 06:13:58 -0000 X-Spam-Check-By: sourceware.org Received: from omta04sl.mx.bigpond.com (HELO omta04sl.mx.bigpond.com) (144.140.93.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Jul 2006 06:13:56 +0000 Received: from grove.modra.org ([60.226.255.233]) by omta04sl.mx.bigpond.com with ESMTP id <20060703061352.VTOX7229.omta04sl.mx.bigpond.com@grove.modra.org>; Mon, 3 Jul 2006 06:13:52 +0000 Received: by bubble.grove.modra.org (Postfix, from userid 500) id 4065B1E5B42; Mon, 3 Jul 2006 15:43:52 +0930 (CST) Date: Mon, 03 Jul 2006 06:14:00 -0000 From: Alan Modra To: Jakub Jelinek Cc: binutils@sources.redhat.com Subject: Re: [PATCH] Fix compute_bucket_count Message-ID: <20060703061352.GP4388@bubble.grove.modra.org> Mail-Followup-To: Jakub Jelinek , binutils@sources.redhat.com References: <20060623155502.GT3823@sunsite.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623155502.GT3823@sunsite.mff.cuni.cz> User-Agent: Mutt/1.4i X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00007.txt.bz2 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