From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14056 invoked by alias); 3 Jul 2006 08:42:36 -0000 Received: (qmail 14048 invoked by uid 22791); 3 Jul 2006 08:42:36 -0000 X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Jul 2006 08:42:34 +0000 Received: from sunsite.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k638gVqm024417 for ; Mon, 3 Jul 2006 10:42:31 +0200 Received: (from jj@localhost) by sunsite.mff.cuni.cz (8.13.1/8.13.1/Submit) id k638gV3s024416 for binutils@sources.redhat.com; Mon, 3 Jul 2006 10:42:31 +0200 Date: Mon, 03 Jul 2006 08:42:00 -0000 From: Jakub Jelinek To: binutils@sources.redhat.com Subject: Re: [PATCH] Fix compute_bucket_count Message-ID: <20060703084231.GB3823@sunsite.mff.cuni.cz> Reply-To: Jakub Jelinek References: <20060623155502.GT3823@sunsite.mff.cuni.cz> <20060703061352.GP4388@bubble.grove.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060703061352.GP4388@bubble.grove.modra.org> User-Agent: Mutt/1.4.1i 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/msg00009.txt.bz2 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