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 11:10 AM, sami wagiaalla <swagiaal@redhat.com> wrote:
> Yup exactly. This part of the patch caused the problem:
>
>> ? /* Helper function, initialises partial symbol structure and stashes
>> ? ? ?it into objfile's bcache. ?Note that our caching mechanism will
>> ? ? ?use all fields of struct partial_symbol to determine hash value of the
>> @@ -1285,15 +1326,8 @@ add_psymbol_to_bcache (char *name, int namelength, int copy_name,
>> ? ? ? ? ? ? ? ? ? ? ?enum language language, struct objfile *objfile,
>> ? ? ? ? ? ? ? ? ? ? ?int *added)
>> ? {
>> - ?/* psymbol is static so that there will be no uninitialized gaps in the
>> - ? ? structure which might contain random data, causing cache misses in
>> - ? ? bcache. */
>> - ?static 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:
>
> ?memset (&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?


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