Re: [RFC/RFA] dangling bfd pointer in archive cache...

[Alan Modra <amodra at gmail dot com>]

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