From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2420 invoked by alias); 3 Oct 2012 13:30:34 -0000 Received: (qmail 2387 invoked by uid 22791); 3 Oct 2012 13:30:32 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Oct 2012 13:30:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A203F1C6277; Wed, 3 Oct 2012 09:30:27 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IJ3lqmxX1C+R; Wed, 3 Oct 2012 09:30:27 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 472481C618D; Wed, 3 Oct 2012 09:30:27 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B3CA7C67FF; Wed, 3 Oct 2012 15:30:19 +0200 (CEST) Date: Wed, 03 Oct 2012 13:30:00 -0000 From: Joel Brobecker To: binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [RFC/RFA] dangling bfd pointer in archive cache... Message-ID: <20121003133019.GE3028@adacore.com> References: <20121002141405.GD3028@adacore.com> <20121003052937.GB25219@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121003052937.GB25219@bubble.grove.modra.org> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00034.txt.bz2 Hello Alan, Thanks for the review! > On Tue, Oct 02, 2012 at 07:14:06AM -0700, Joel Brobecker wrote: > > * opncls.c (bfd_close); Add call to _bfd_archive_close_and_cleanup. > > No, we should already be calling _bfd_archive_close_and_cleanup via OK, but before I go ahead with your implementation, I wanted to make sure about something... > > --- a/bfd/opncls.c > > +++ b/bfd/opncls.c > > @@ -719,6 +719,17 @@ bfd_close (bfd *abfd) > > if (! BFD_SEND (abfd, _close_and_cleanup, (abfd))) > > this call. The problem is in coff-rs6000.c (and coff64-rs6000.c) > where the bfd_target vector just uses bfd_true for close_and_cleanup. ... My reasoning is that this part of the job isn't target-specific. It's entirely related to how the generic side of archives is handled, not to the target itself. To me, it needs to be called regardless of the actual target, and requiring that the target code set it up is a recipe for having some of them forgetting to do it (which is what actually happened here). WDYT? Am I wrong? -- Joel