From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4389 invoked by alias); 16 Aug 2010 19:56:02 -0000 Received: (qmail 4380 invoked by uid 22791); 16 Aug 2010 19:56:01 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,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; Mon, 16 Aug 2010 19:55:56 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7GJttUQ022876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Aug 2010 15:55:55 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7GJtsiR007881 for ; Mon, 16 Aug 2010 15:55:54 -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 o7GJtslm012091 for ; Mon, 16 Aug 2010 15:55:54 -0400 Message-ID: <4C6997B4.9090605@redhat.com> Date: Mon, 16 Aug 2010 19:56: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/msg00242.txt.bz2 > 1) We store symbol names such that we can compare them with ptr1 == > ptr2, but your patch uses strcmp. that explains how the old hash function worked :) > 2) I'm wondering if there's some abstraction violation with bcache not > being aware of the extra memory that is used by > gsymbol->language_specific.cplus_specific. Dunno, just wondering. I think it is okay as long as the part of psymbol taken into consideration ensures that duplicate symbols are caught (Daniel had some comments here). Also, this is only for psymbols. Other clients still use the old hash function