Unreliable BFD caching heuristic

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