Re: Unreliable BFD caching heuristic

>>>>> "Luis" == Luis Machado <[email protected]> writes:

Luis> If all those things happen at the same time, the BFD machinery will
Luis> attempt to use a cached entry to load data from a totally new
Luis> binary. From that point onwards, things just go downhill.

Luis> This is really a regression compared to older GDB's, and a solution
Luis> probably involves improving the matching heuristics, in
Luis> gdb/gdb_bfd.c:eq_bfd, with more data.

Another idea occurred to me recently, which is that gdb could use
inotify to notice when a file is changed.  However this only works on
some limited set of hosts.  It's probably overkill as well.

There's actually a second problem here: the BFD file descriptor cache
(see bfd/cache.c).  Sometimes gdb closes all the file descriptors in
this cache, and BFD will reopen them without considering whether the
file has changed.  So, it is probably possible to construct test cases
that fail even with older versions of gdb.

Even on Linux I think gdb sometimes needs to close the file descriptors
-- e.g., when "set write on" is in effect, "run" needs to close them to
avoid ETXTBSY.  I'm not sure how to solve this.

Yet another idea lurking in here is that if a file does change, we
should probably disable trust-readonly-sections for it.

Tom