From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-75339-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 21318 invoked by alias); 1 Sep 2010 18:24:27 -0000
Received: (qmail 21309 invoked by uid 22791); 1 Sep 2010 18:24:26 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Sep 2010 18:24:21 +0000
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7])	by smtp-out.google.com with ESMTP id o81IOILw025955	for <gdb-patches@sourceware.org>; Wed, 1 Sep 2010 11:24:19 -0700
Received: from vws14 (vws14.prod.google.com [10.241.21.142])	by hpaq7.eem.corp.google.com with ESMTP id o81IOHAJ015145	for <gdb-patches@sourceware.org>; Wed, 1 Sep 2010 11:24:17 -0700
Received: by vws14 with SMTP id 14so7199559vws.25        for <gdb-patches@sourceware.org>; Wed, 01 Sep 2010 11:24:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.60.204 with SMTP id q12mr4223748vch.20.1283365434638; Wed, 01 Sep 2010 11:23:54 -0700 (PDT)
Received: by 10.220.200.73 with HTTP; Wed, 1 Sep 2010 11:23:54 -0700 (PDT)
In-Reply-To: <4C7E96FA.2080209@redhat.com>
References: <4C6946E1.6000709@redhat.com>	<AANLkTikH1rBzysO-nNT-w3a0me7zMcGfSpn7+7oJQdWk@mail.gmail.com>	<AANLkTikbMcvP-+2iqZB3gP-gLcWY7B7r4t+HWtHK-a6f@mail.gmail.com>	<4C6D5C83.3050602@redhat.com>	<m3eidu2vt7.fsf@fleche.redhat.com>	<4C756132.5050301@redhat.com>	<20100901082539.GA24609@host1.dyn.jankratochvil.net>	<20100901161952.GX2986@adacore.com>	<20100901164716.GY2986@adacore.com>	<4C7E96FA.2080209@redhat.com>
Date: Wed, 01 Sep 2010 18:24:00 -0000
Message-ID: <AANLkTiktKEH04642oBgKC1LJO2jwp4zF4941Z6L3dM3H@mail.gmail.com>
Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]
From: Doug Evans <dje@google.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: gdb-patches@sourceware.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2010-09/txt/msg00034.txt.bz2

On Wed, Sep 1, 2010 at 11:10 AM, sami wagiaalla <swagiaal@redhat.com> wrote:
> Yup exactly. This part of the patch caused the problem:
>
>> =A0 /* Helper function, initialises partial symbol structure and stashes
>> =A0 =A0 =A0it into objfile's bcache. =A0Note that our caching mechanism =
will
>> =A0 =A0 =A0use all fields of struct partial_symbol to determine hash val=
ue of the
>> @@ -1285,15 +1326,8 @@ add_psymbol_to_bcache (char *name, int namelength=
, int copy_name,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enum language language, struc=
t objfile *objfile,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int *added)
>> =A0 {
>> - =A0/* psymbol is static so that there will be no uninitialized gaps in=
 the
>> - =A0 =A0 structure which might contain random data, causing cache misse=
s in
>> - =A0 =A0 bcache. */
>> - =A0static struct partial_symbol psymbol;
>> -
>
> I thought this was OK because the new hash function looked only at the
> initialized fields. Of course this left obj_section uninitialized.
> Adding:
>
> =A0memset (&psymbol, 0, sizeof (psymbol));
>
> seems to fix the problem:

One would expect the original code to have done a memset too, instead
of using "static".  Presumably it didn't for performance reasons.  Do
we know if the performance concerns were real?