Re: Unreliable BFD caching heuristic

[Luis Machado <lgustavo@codesourcery.com>]

On 12/02/2013 01:42 PM, Tom Tromey wrote:
>>>>>> "Luis" == Luis Machado <lgustavo@codesourcery.com> 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.

It seems to be the case. That will need to be fixed eventually.

>
> 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.

Right. For now, it seems the ELF headers provide enough information to 
tell two different files apart.

The problem there is that we need to open the BFD and read some of its 
data, which in turn requires us to detect architecture size and 
endianness. Only then we will be able to see if we are dealing with two 
different files.

I did an experiment with using the inode number in the cache check. It 
seems to work for the hosts that support that information. On Windows i 
think we fake inode numbers based on the file name and timestamp, so it 
could be a simpler solution.

Luis