Re: who owns a BFD coming from an archive?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Alan" == Alan Modra <amodra@gmail.com> writes:

Tom> * For a thin archive, again according to valgrind and my reading, the
Tom> opposite is true: the archive owns the BFDs, and if you close each
Tom> one, you will see crashes.

Alan> Thin archives support nesting.  I think the BFDs opened to access
Alan> nested archives are owned by the archive, BFDs returned for objects
Alan> are owned by you.  However it is all quite nasty due to the archive
Alan> cache.

Thanks for replying.

I wrote some patches to fix all the problems I know of.
They fix my simple test case, but I'm still looking through the rest of
binutils, etc, to make sure they will work ok (or to fix up whatever
issues I see).

I found out that I was confused about thin archives.  What I was seeing
is that with flattened thin archives, the outer archive BFD owns the
inner archive BFD -- but this inner archive BFD is invisible to the BFD
user, so the special treatment inside BFD is warranted.

Alan> I think you'll see crashes due to the cache with normal archives too,
Alan> eg. call get_elt_at_index, close the returned bfd, then call
Alan> get_elt_at_index with the same position again.  You can also easily
Alan> crash with openr_next_archived_file if you close the current member
Alan> bfd before opening the next one..

Yeah.  I didn't change this, on the theory that it is implied by the API
for bfd_openr_next_archived_file.


The approach I took is:

* Archive members must be closed like any other BFD.
  (You can of course still leave them open and exit.)
* However, archive members aren't fully independent of their parent
  BFD.  So, if you close the parent, you must not use any open children.

I looked at trying to make archive members fully independent, but this
looked difficult.

Maybe it could be done for thin archive members, but I thought
consistency was preferable.

I didn't deal with output BFD archives and handling archive_head.  I
don't know anything about those.


If this sounds like a bad plan, I'd appreciate a heads up.

Tom