This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Use custom hash function with bcache
- From: Tom Tromey <tromey at redhat dot com>
- To: sami wagiaalla <swagiaal at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 17 Aug 2010 17:26:20 -0600
- Subject: Re: [RFC] Use custom hash function with bcache
- References: <4C6946E1.6000709@redhat.com>
>>>>> "Sami" == sami wagiaalla <swagiaal@redhat.com> writes:
Sami> This patch enables the use of custom hash and comparison functions
Sami> when adding elements to a bcache. The patch also introduces hash and
Sami> comparison functions which take into consideration only the relevant
Sami> properties of the psymbol.
I don't understand how this approach can work as-is.
The bcache interns objects. It doesn't know anything about their
semantics, just their size.
This patch means that a given bcache could include two objects of the
same size that have different hash and comparison functions. So, it
seems like some kind of clash could (in theory) result. This is very
bad if one object is mutable and the other is not.
I think it would be safer to either:
1. Make the hash and comparison functions part of the bcache itself, set
only when the bcache is allocated, then audit all uses of this
particular bcache to make sure that only psymtabs are added to it
(this could be done by introducing a new type, so that invalid uses
are compile-time errors),
or
2. Do psymtab interning in an htab_t. I suspect this will have worse
overhead, but I really don't know.
I think you can make the psym hash and comparison functions a bit
simpler by just skipping the pointer-sized lang-specific hole. This is
maybe more future-proof as well.
Tom