From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20119 invoked by alias); 3 Dec 2013 15:28:08 -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 20034 invoked by uid 89); 3 Dec 2013 15:28:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED 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; Tue, 03 Dec 2013 15:28:05 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Vnrt7-0003cc-SD from Luis_Gustavo@mentor.com ; Tue, 03 Dec 2013 07:27:49 -0800 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 07:27:49 -0800 Received: from [172.30.5.78] ([172.30.5.78]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Dec 2013 07:27:49 -0800 Message-ID: <529DF865.2070104@codesourcery.com> Date: Tue, 03 Dec 2013 15:28: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: Tom Tromey CC: "gdb@sourceware.org" , "Maciej W. Rozycki" Subject: Re: Unreliable BFD caching heuristic References: <528E454F.6060003@codesourcery.com> <87a9gjw97b.fsf@fleche.redhat.com> In-Reply-To: <87a9gjw97b.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00004.txt.bz2 On 12/02/2013 01:42 PM, Tom Tromey wrote: >>>>>> "Luis" == Luis Machado writes: > > Luis> If all those things happen at the same time, the BFD machinery will > Luis> attempt to use a cached entry to load data from a totally new > Luis> binary. From that point onwards, things just go downhill. > > Luis> This is really a regression compared to older GDB's, and a solution > Luis> probably involves improving the matching heuristics, in > Luis> gdb/gdb_bfd.c:eq_bfd, with more data. > > Another idea occurred to me recently, which is that gdb could use > inotify to notice when a file is changed. However this only works on > some limited set of hosts. It's probably overkill as well. > > There's actually a second problem here: the BFD file descriptor cache > (see bfd/cache.c). Sometimes gdb closes all the file descriptors in > this cache, and BFD will reopen them without considering whether the > file has changed. So, it is probably possible to construct test cases > that fail even with older versions of gdb. It seems to be the case. That will need to be fixed eventually. > > Even on Linux I think gdb sometimes needs to close the file descriptors > -- e.g., when "set write on" is in effect, "run" needs to close them to > avoid ETXTBSY. I'm not sure how to solve this. > > Yet another idea lurking in here is that if a file does change, we > should probably disable trust-readonly-sections for it. Right. For now, it seems the ELF headers provide enough information to tell two different files apart. The problem there is that we need to open the BFD and read some of its data, which in turn requires us to detect architecture size and endianness. Only then we will be able to see if we are dealing with two different files. I did an experiment with using the inode number in the cache check. It seems to work for the hosts that support that information. On Windows i think we fake inode numbers based on the file name and timestamp, so it could be a simpler solution. Luis