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 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


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