From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8606 invoked by alias); 17 Aug 2010 17:02:41 -0000 Received: (qmail 8406 invoked by uid 22791); 17 Aug 2010 17:02:39 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,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; Tue, 17 Aug 2010 17:02:32 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7HH2UF4007319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Aug 2010 13:02:30 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7HH2U9S005844 for ; Tue, 17 Aug 2010 13:02:30 -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 o7HH2TM3012701 for ; Tue, 17 Aug 2010 13:02:29 -0400 Message-ID: <4C6AC07A.1040303@redhat.com> Date: Tue, 17 Aug 2010 17:02: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> <20100816191348.GA16221@caradoc.them.org> <4C699679.6090209@redhat.com> <20100816200325.GA19823@caradoc.them.org> <4C699B55.5000601@redhat.com> <20100816204947.GA22993@caradoc.them.org> In-Reply-To: <20100816204947.GA22993@caradoc.them.org> 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/msg00259.txt.bz2 > Aha! OK, I get it now. And the section is probably never used for > psymbols, right? > It might be if the symbol is a C++ symbol and has a demangled name. > I think that the way you've got this is probably OK, but could stand > some more explanation. I will update the comments to reflect the result our discussions here. It kind of pains me, though, because there's > an obvious missed optimization that I don't see how to do efficiently. > We don't need to do the work of SYMBOL_SET_NAMES again if there's already a > named version in the cache... > Hmm... this is probably a separate patch, but how about this: symbol_set_names sets the mangled and demangled names we need at least the mangled name to find out wether there is already a name version in the bcache. So maybe we could only set the mangled name, check the bcache and only set the demangled name after we have consulted the bcache. This only works of course if we ignore the demangled name as is in this patch (Do you agree that this is OK btw ?).