This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Unreliable BFD caching heuristic
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>, Tom Tromey <tromey at redhat dot com>, "Maciej W. Rozycki" <macro at codesourcery dot com>
- Date: Thu, 21 Nov 2013 15:39:27 -0200
- Subject: Unreliable BFD caching heuristic
- Authentication-results: sourceware.org; auth=none
- Reply-to: lgustavo at codesourcery dot com
Hi,
Just recently i was chasing a bug in an automated GCC testing
environment that uses GDB to run the programs GCC builds.
Some tests in GCC's testsuite create a number of different binaries with
the same name, one after the other, with different flags.
The bug happens when GDB loads all of those binaries, one at a time
obviously, in a single session, with a pattern of loading, running,
loading, running...
That's when the BFD caching takes effect and starts trying to save
resources based on two pieces of information: file name and the file's
modification timestamp.
In summary, if you are using a reasonably fast build system that can
create multiple binaries per second, you can potentially end up with two
or more binaries with the same file modification timestamp.
If all those things happen at the same time, the BFD machinery will
attempt to use a cached entry to load data from a totally new binary.
From that point onwards, things just go downhill.
This is really a regression compared to older GDB's, and a solution
probably involves improving the matching heuristics, in
gdb/gdb_bfd.c:eq_bfd, with more data.
Experiments show that using the file size in eq_bfd helps a little, but
i've managed to trigger the bug with that as well, plus it does not
address the problem of having multiple BFD's inside an archive.
Since we have hash functions available, Maciej (cc-ed) suggested
creating a hash number based on ELF header information, which sounds
like a good approach.
I can also see how this bug would happen under systems with low
resolution timestamps or with filesystems that do not provide precise
timestamp information.
Do you have any proposals on ways to improve this heuristic?
As an example, here is a list of binaries GCC generates for a testcase
(with unique names so we can compare them side-by-side). Notice their
timestamps.
Size Timestamp Name
107223 2013-11-20 19:53:01.758737300 -0800 20020220-1-10.exe
106727 2013-11-20 19:53:01.758737300 -0800 20020220-1-11.exe
106727 2013-11-20 19:53:01.758737300 -0800 20020220-1-12.exe
107303 2013-11-20 19:53:01.758737300 -0800 20020220-1-13.exe
106727 2013-11-20 19:53:02.258781643 -0800 20020220-1-14.exe
106727 2013-11-20 19:53:02.258781643 -0800 20020220-1-15.exe
107303 2013-11-20 19:53:02.258781643 -0800 20020220-1-16.exe
106727 2013-11-20 19:53:02.258781643 -0800 20020220-1-17.exe
106727 2013-11-20 19:53:02.757667981 -0800 20020220-1-18.exe
107575 2013-11-20 19:53:02.757667981 -0800 20020220-1-19.exe
107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-20.exe
107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-21.exe
107655 2013-11-20 19:53:02.757667981 -0800 20020220-1-22.exe
107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-23.exe
107079 2013-11-20 19:53:02.757667981 -0800 20020220-1-24.exe
107655 2013-11-20 19:53:03.258763445 -0800 20020220-1-25.exe
107079 2013-11-20 19:53:03.258763445 -0800 20020220-1-26.exe
107079 2013-11-20 19:53:03.258763445 -0800 20020220-1-27.exe
104930 2013-11-20 19:53:01.258799713 -0800 20020220-1-2.exe
104962 2013-11-20 19:53:01.258799713 -0800 20020220-1-3.exe
105890 2013-11-20 19:53:01.258799713 -0800 20020220-1-4.exe
105170 2013-11-20 19:53:01.258799713 -0800 20020220-1-5.exe
105218 2013-11-20 19:53:01.258799713 -0800 20020220-1-6.exe
116934 2013-11-20 19:53:01.758737300 -0800 20020220-1-7.exe
116214 2013-11-20 19:53:01.758737300 -0800 20020220-1-8.exe
116270 2013-11-20 19:53:01.758737300 -0800 20020220-1-9.exe
105378 2013-11-20 19:52:57.758767853 -0800 20020220-1.exe
Regards,
Luis