This is the mail archive of the
mailing list for the binutils project.
Re: [RFC/RFA] dangling bfd pointer in archive cache...
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.
Australia Development Lab, IBM