[Bug binutils/15545] BFD cache modifies cacheable flag

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15545

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Nick Clifton from comment #4)

> > One option might be to save the mode so that the cache
> > can properly reopen all closed fds.
> 
> I do not think that this will work.  When bfd_cache_close_all()
> calls fclose() all information is lost/made invalid, including 
> the file descriptor that was passed to bfd_fopen() in the first
> place.  So in order to be able to reopen the file bfd_fopen()
> would need to find out (or be told) the mode, flags and pathname 
> used to create the original file descriptor and then save them
> somewhere.
> 

Yeah, that's exactly my proposal -- save the mode in the bfd
or some cache-affiliated object, so that it can be passed to fopen.
I don't think there's any separate flags to save?  Just the
'mode' argument to bfd_fopen.

> I still like my original solution.  If a bfd has been opened
> in such a way that it is uncacheable, then code should not 
> expect to close it and then magically have it be reopened.

> That should be fairly easy to code.  It would also be worthwhile updating
> the description of the bfd_cache_close_all() function to specifically
> mention that it will close uncacheable files, and pointing the reader at
> this new function as an alternative.

Yeah.

I probably shouldn't have filed this bug since I think the fix will
actually break gdb.  At least, the proposals other than saving the
mode will.  E.g., solib_bfd_fopen opens the solib by passing
in an fd but may rely on reopening this due to lazy DWARF reading.

> Aside - it looks there is a potential infinite loop problem with
> bfd_cache_close_all() since the call to bfd_cache_close() can 
> return without having changed bfd_last_cache:
> 
>   while (bfd_last_cache != NULL)
>     ret &= bfd_cache_close (bfd_last_cache);
> 
> So this ought to be fixed too.

This could only happen if somehow a non-cached BFD ends up
on bfd_last_cache.  In gdb we'd probably add asserts for this
kind of thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.