Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]

[sami wagiaalla <swagiaal@redhat.com>]

On 09/01/2010 03:14 PM, Doug Evans wrote:
> On Wed, Sep 1, 2010 at 12:01 PM, sami wagiaalla<swagiaal@redhat.com>  wrote:
>> On 09/01/2010 02:37 PM, Tom Tromey wrote:
>>>>>>>>
>>>>>>>> "Doug" == Doug Evans<dje@google.com>    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