From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3045 invoked by alias); 4 Oct 2012 08:01:35 -0000 Received: (qmail 2889 invoked by uid 22791); 4 Oct 2012 08:01:32 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pb0-f41.google.com (HELO mail-pb0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Oct 2012 08:01:28 +0000 Received: by mail-pb0-f41.google.com with SMTP id rq2so391769pbb.0 for ; Thu, 04 Oct 2012 01:01:28 -0700 (PDT) Received: by 10.66.84.229 with SMTP id c5mr11200144paz.76.1349337688119; Thu, 04 Oct 2012 01:01:28 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPS id st6sm3959767pbc.58.2012.10.04.01.01.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 01:01:27 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 9D197EA0243; Thu, 4 Oct 2012 17:31:21 +0930 (CST) Date: Thu, 04 Oct 2012 08:01:00 -0000 From: Alan Modra To: Joel Brobecker Cc: binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [RFC/RFA] dangling bfd pointer in archive cache... Message-ID: <20121004080121.GF25219@bubble.grove.modra.org> Mail-Followup-To: Joel Brobecker , binutils@sourceware.org, gdb-patches@sourceware.org References: <20121002141405.GD3028@adacore.com> <20121003052937.GB25219@bubble.grove.modra.org> <20121003133019.GE3028@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121003133019.GE3028@adacore.com> 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/msg00059.txt.bz2 On Wed, Oct 03, 2012 at 06:30:19AM -0700, Joel Brobecker wrote: > 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. but it may become target specific at some future date.. > 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). This is not the first time we've seen this sort of problem, due to coff-rs6000.c filling in a bfd_target struct by hand. I don't know why it wasn't written to use one of the COFF_TARGET_VEC macros, or at the very least, using all the BFD_JUMP_TABLE macros. -- Alan Modra Australia Development Lab, IBM