This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 and that's sufficient?  So do we need
the memset of the original patch (which only zeros
psymbol.ginfo.value).

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?).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]