From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15764 invoked by alias); 1 Sep 2010 19:28:12 -0000 Received: (qmail 15746 invoked by uid 22791); 1 Sep 2010 19:28:09 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Sep 2010 19:28:03 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o81JRxju010610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Sep 2010 15:28:00 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o81JRxKG026116; Wed, 1 Sep 2010 15:27:59 -0400 Received: from [10.15.16.129] (dhcp-10-15-16-129.yyz.redhat.com [10.15.16.129]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o81JRwDL020174; Wed, 1 Sep 2010 15:27:58 -0400 Message-ID: <4C7EA94E.4010104@redhat.com> Date: Wed, 01 Sep 2010 19:59:00 -0000 From: sami wagiaalla User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Evans CC: Tom Tromey , gdb-patches@sourceware.org Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache] References: <4C6946E1.6000709@redhat.com> <4C6D5C83.3050602@redhat.com> <4C756132.5050301@redhat.com> <20100901082539.GA24609@host1.dyn.jankratochvil.net> <20100901161952.GX2986@adacore.com> <20100901164716.GY2986@adacore.com> <4C7E96FA.2080209@redhat.com> <4C7EA30B.7020007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00056.txt.bz2 On 09/01/2010 03:14 PM, Doug Evans wrote: > On Wed, Sep 1, 2010 at 12:01 PM, sami wagiaalla wrote: >> On 09/01/2010 02:37 PM, Tom Tromey wrote: >>>>>>>> >>>>>>>> "Doug" == Doug Evans writes: >>> >>> Doug> One would expect the original code to have done a memset too, >>> instead >>> Doug> of using "static". Presumably it didn't for performance reasons. >>> Do >>> Doug> we know if the performance concerns were real? >>> >>> No, we don't know. >>> It is safest to just revert to what it was before. > > I hope I'm not reducing the S/N ratio here, but there's something I > don't understand. > The original patch doesn't initialize obj_section (right?) (except by > virtue of using "static"). So if this fixes things, does it do so > only because we're taking advantage of the fact that obj_section will > be NULL in the static version Yes. and that's sufficient? IIUC, it should be. So do we need > the memset of the original patch (which only zeros > psymbol.ginfo.value). > I don't really see why it is needed but I am inclined to believe the comment. > Plus, reverting to the original patch leaves me a little > uncomfortable: There's a comment that mentions gaps in the struct > causing cache misses, but that's no longer an issue with the custom > hash function (right?). I should probably fix that comment. The gabs in the struct, while bad, would not cause hash misses since the new supplied hash function only looks at the initialized fields. Sami