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.
