From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22701 invoked by alias); 25 Nov 2013 17:45:51 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22687 invoked by uid 89); 25 Nov 2013 17:45:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Nov 2013 17:45:49 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Vl0E1-0002ZW-69 from Luis_Gustavo@mentor.com ; Mon, 25 Nov 2013 09:45:33 -0800 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by svr-orw-fem-01.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Nov 2013 09:45:32 -0800 Received: from [172.30.4.216] ([172.30.4.216]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Nov 2013 09:45:32 -0800 Message-ID: <52938CB2.8080700@codesourcery.com> Date: Mon, 25 Nov 2013 17:45:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Pedro Alves CC: "gdb@sourceware.org" , Tom Tromey , "Maciej W. Rozycki" Subject: Re: Unreliable BFD caching heuristic References: <528E454F.6060003@codesourcery.com> <528E49B8.8090409@redhat.com> In-Reply-To: <528E49B8.8090409@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00094.txt.bz2 On 11/21/2013 03:58 PM, Pedro Alves wrote: > On 11/21/2013 05:39 PM, Luis Machado wrote: >> Do you have any proposals on ways to improve this heuristic? > > Compare st_ino/st_dev, and don't share if the system doesn't > provide meaningful bfd_stat data? > > symfile.c:separate_debug_file_exists does this already, > and then does a CRC check if all else fails. Not sure > whether the CRC part would be a good idea here. > I don't think the inode and device information are portable enough for us to use. The file CRC seems more appropriate in terms of portability, but we need to open the bfd, check the CRC and (maybe) close it if we find a cached entry. Sounds like a potential performance drawback, but it is more reliable IMO. We can't rely on the timestamp due to some filesystems having 1 second or 2 seconds resolution. That doesn't seem enough. Luis