From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7038 invoked by alias); 2 Dec 2013 15:42:45 -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 7025 invoked by uid 89); 2 Dec 2013 15:42:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED 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, 02 Dec 2013 15:42:42 +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 rB2FgYnq008279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Dec 2013 10:42:34 -0500 Received: from barimba (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rB2FgWOR013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Dec 2013 10:42:33 -0500 From: Tom Tromey To: lgustavo@codesourcery.com Cc: "gdb\@sourceware.org" , "Maciej W. Rozycki" Subject: Re: Unreliable BFD caching heuristic References: <528E454F.6060003@codesourcery.com> Date: Mon, 02 Dec 2013 15:42:00 -0000 In-Reply-To: <528E454F.6060003@codesourcery.com> (Luis Machado's message of "Thu, 21 Nov 2013 15:39:27 -0200") Message-ID: <87a9gjw97b.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00001.txt.bz2 >>>>> "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. 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. Tom