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: [RFC] Use custom hash function with bcache


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


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