This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Unreliable BFD caching heuristic
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>, "Maciej W. Rozycki" <macro at codesourcery dot com>
- Date: Tue, 03 Dec 2013 13:27:33 -0200
- Subject: Re: Unreliable BFD caching heuristic
- Authentication-results: sourceware.org; auth=none
- References: <528E454F dot 6060003 at codesourcery dot com> <87a9gjw97b dot fsf at fleche dot redhat dot com>
- Reply-to: lgustavo at codesourcery dot 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