From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5067 invoked by alias); 18 Aug 2010 15:13:13 -0000 Received: (qmail 5052 invoked by uid 22791); 18 Aug 2010 15:13:11 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Aug 2010 15:13:06 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7IFD5w4002564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Aug 2010 11:13:05 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7IFD4Kw027358 for ; Wed, 18 Aug 2010 11:13:04 -0400 Received: from [10.15.16.129] (dhcp-10-15-16-129.yyz.redhat.com [10.15.16.129]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o7IFD3ms019663 for ; Wed, 18 Aug 2010 11:13:04 -0400 Message-ID: <4C6BF870.7010203@redhat.com> Date: Wed, 18 Aug 2010 15:13:00 -0000 From: sami wagiaalla User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFC] Use custom hash function with bcache References: <4C6946E1.6000709@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00299.txt.bz2 > 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: I will take door number 1 since I am already working on it :) > 1. Make the hash and comparison functions part of the bcache itself, set > only when the bcache is allocated, This is what Doug suggested. Making the functions part of the bcache struct and assigning them when bcache_xmalloc is called. 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), with the above change the bcaches will be initialized like this: objfile->psymbol_cache = bcache_xmalloc (psymbol_hash, psymbol_compare); objfile->macro_cache = bcache_xmalloc (NULL, NULL); objfile->filename_cache = bcache_xmalloc (NULL, NULL); So only objects added to the psymbol_cache would be subjected to the new hash and compare functions. Although, you are right, there is no strict type checking. Are you suggesting we make psymbol_cache a new type ? > > 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. > This patch already does that :)