From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2821 invoked by alias); 27 Oct 2005 02:51:10 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2777 invoked by uid 22791); 27 Oct 2005 02:51:00 -0000 Received: from omta02sl.mx.bigpond.com (HELO omta02sl.mx.bigpond.com) (144.140.93.154) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 27 Oct 2005 02:51:00 +0000 Received: from grove.modra.org ([144.136.167.90]) by omta02sl.mx.bigpond.com with ESMTP id <20051027025053.UUP21196.omta02sl.mx.bigpond.com@grove.modra.org> for ; Thu, 27 Oct 2005 02:50:53 +0000 Received: by bubble.grove.modra.org (Postfix, from userid 500) id C5012557DE; Thu, 27 Oct 2005 12:20:52 +0930 (CST) Date: Thu, 27 Oct 2005 02:51:00 -0000 From: Alan Modra To: gdb@sources.redhat.com Subject: Re: PR 2014, 2007, 1968, 1945, 1935, 1865, 1823 Message-ID: <20051027025052.GT17244@bubble.grove.modra.org> References: <20051027011411.GS17244@bubble.grove.modra.org> <20051027020124.GA10568@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051027020124.GA10568@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2005-10/txt/msg00148.txt.bz2 On Wed, Oct 26, 2005 at 10:01:24PM -0400, Daniel Jacobowitz wrote: > Oh, while you're in the area: ISTR finding that BFD was missing > O_LARGEFILE somewhere that GDB had it. So if GDB opened the core file, > and then BFD closed and reopened it, the open would fail. Yes, there was a silly check in bfd_cache_lookup_worker that tested for abfd->where being in unsigned long range. That's gone, but I guess there might be other places similarly broken. I'm also working on the following tweaks to bfd_cache_lookup. /* In some cases we can optimize cache operation when reopening files. For instance, a flush is entirely unnecessary if the file is already closed, so a flush would use CACHE_NO_OPEN. Similarly, a seek using SEEK_SET or SEEK_END need not first seek to the current position. For stat we ignore seek errors, because stat might be used (eg. by gdb) to determine whether a file has changed while we weren't looking. If it has, then it's possible that the new file is shorter and we don't want a seek error to prevent us doing the stat. */ enum cache_flag { CACHE_NORMAL = 0, CACHE_NO_OPEN = 1, CACHE_NO_SEEK = 2, CACHE_NO_SEEK_ERROR = 4 }; -- Alan Modra IBM OzLabs - Linux Technology Centre