This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Alan Modra
Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]