From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14103 invoked by alias); 16 Aug 2010 19:14:05 -0000 Received: (qmail 14093 invoked by uid 22791); 16 Aug 2010 19:14:04 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_05,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Aug 2010 19:13:59 +0000 Received: (qmail 32715 invoked from network); 16 Aug 2010 19:13:57 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Aug 2010 19:13:57 -0000 Date: Mon, 16 Aug 2010 19:14:00 -0000 From: Daniel Jacobowitz To: sami wagiaalla Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Use custom hash function with bcache Message-ID: <20100816191348.GA16221@caradoc.them.org> Mail-Followup-To: sami wagiaalla , gdb-patches@sourceware.org References: <4C6946E1.6000709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6946E1.6000709@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00238.txt.bz2 On Mon, Aug 16, 2010 at 10:10:41AM -0400, sami wagiaalla wrote: > This patch enables the use of custom hash and comparison functions > when adding elements to a bcache. The patch also introduces hash and > comparison functions which take into consideration only the relevant > properties of the psymbol. This patch makes me nervous because it's violating the invariants of the bcache. Any time you get a psymbol from the bcache, it is going to have other fields that were not hashed somewhat random. What are those ignored fields, and why do they not matter? How about lifetimes, are they as long-lived as the bcache? You compare name, value, language, domain, and class. The mangled name is ignored; this assumes that there is only ever one mangled name per demangled name, with no documentation of why that's safe to assume. Section is ignored; if there are two definitions of a symbol with the same name in different sections but the same value otherwise, we'll never find out. That could break overlays. -- Daniel Jacobowitz CodeSourcery