From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13733 invoked by alias); 25 Nov 2013 18:08:31 -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 13721 invoked by uid 89); 25 Nov 2013 18:08:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_50,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 18:08:29 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Vl0Zy-0006eT-5z from Maciej_Rozycki@mentor.com ; Mon, 25 Nov 2013 10:08:14 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Nov 2013 10:08:14 -0800 Received: from [172.30.64.225] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Mon, 25 Nov 2013 18:08:12 +0000 Date: Mon, 25 Nov 2013 18:08:00 -0000 From: "Maciej W. Rozycki" To: Luis Machado CC: Pedro Alves , "gdb@sourceware.org" , Tom Tromey Subject: Re: Unreliable BFD caching heuristic In-Reply-To: <52938CB2.8080700@codesourcery.com> Message-ID: References: <528E454F.6060003@codesourcery.com> <528E49B8.8090409@redhat.com> <52938CB2.8080700@codesourcery.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-11/txt/msg00096.txt.bz2 On Mon, 25 Nov 2013, Luis Machado wrote: > > 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. The system clock may also have a 1 second resolution only (although these are quite rare indeed these days) and a timestamp can be interfered with (unless we check ctime too, but then some filesystems don't store it). Calculating a CRC of the whole file may be unacceptably slow with large executablees and slower targets, and may therefore defeat the very purpose of BFD caching. If we were going down that path, then may I suggest revisiting my original proposal to calculate a CRC or some other hash value instead of raw ELF file/program/section headers (as available) that we need to access anyway (and if cached in BFD, i.e. previously accessed, then chances are to have them in the buffer cache already). Maciej