This is the mail archive of the
mailing list for the GDB project.
Re: Unreliable BFD caching heuristic
- From: Tom Tromey <tromey at redhat dot com>
- To: lgustavo at codesourcery dot com
- Cc: "gdb\ at sourceware dot org" <gdb at sourceware dot org>, "Maciej W. Rozycki" <macro at codesourcery dot com>
- Date: Mon, 02 Dec 2013 08:42:32 -0700
- Subject: Re: Unreliable BFD caching heuristic
- Authentication-results: sourceware.org; auth=none
- References: <528E454F dot 6060003 at codesourcery dot com>
>>>>> "Luis" == Luis Machado <email@example.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.
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.