From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11929 invoked by alias); 25 Nov 2013 18:07:46 -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 11910 invoked by uid 89); 25 Nov 2013 18:07:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Nov 2013 18:07:43 +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.14.4/8.14.4) with ESMTP id rAPI7Y9R002663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Nov 2013 13:07:35 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAPI7WkY021195; Mon, 25 Nov 2013 13:07:33 -0500 Message-ID: <529391E4.3060301@redhat.com> Date: Mon, 25 Nov 2013 18:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: lgustavo@codesourcery.com CC: "gdb@sourceware.org" , Tom Tromey , "Maciej W. Rozycki" Subject: Re: Unreliable BFD caching heuristic References: <528E454F.6060003@codesourcery.com> <528E49B8.8090409@redhat.com> <52938CB2.8080700@codesourcery.com> In-Reply-To: <52938CB2.8080700@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00095.txt.bz2 On 11/25/2013 05:45 PM, Luis Machado wrote: > 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. bfd sharing is a memory optimization. That's why I suggested to not share if not possible to tell (efficiently and) reliably. Comparing st_ino/st_dev between two files is the standard check to use to check whether two files are the same. I don't think we should penalize systems/filesystems that _can_ do this check in the name of portability. Only if that fails would we defer to possibly more expensive fallbacks, like separate_debug_file_exists. > > 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. Right, that's why I wasn't sure it'd be a good idea. Some sort of fingerprinting like Maciej suggested has potential for being cheaper. As usual when considering optimizations, it's a code/memory balance. We can either always optimize for memory and maybe be slow sometimes, or always optimize for speed, and use more memory sometimes. The trick is in finding the sweet spot in between. > We can't rely on the timestamp due to some filesystems having 1 second > or 2 seconds resolution. That doesn't seem enough. -- Pedro Alves