gnulib stat problem (Was: [pushed] Update Gnulib to the latest git version)

[Tom Tromey <tom@tromey.com>]

>> Update Gnulib to the latest git version

I think that this patch introduced a regression on Windows, and I'm
wondering what to do about it.

After merging this in locally, we saw some gdb crashes.  I have a patch
for the crash (will send it soon), but there's still a problem.
Specifically, the first time I "run", gdb always thinks the executable
has changed, even if it has not:

    (gdb) file ./t.exe
    Reading symbols from ./t.exe...
    (gdb) run
    `C:\home\tromey\t.exe' has changed; re-reading symbols.
    Starting program: C:\home\tromey\t.exe 

I believe what is happening here is that gdb is using the gnulib stat
(or fstat or whatever), which adjusts for timezone; but BFD is using
plain stat, which does not.  However, gdb will end up comparing an
time_t coming from the gnulib stat with a time_t coming from
bfd_get_mtime, which causes this problem.

I suppose the principled answer is to change BFD and the rest of the
tree to use gnulib.  This seems like a pain, so I'd rather avoid it.
Also, if binutils doesn't want this, we'll still have the bug.

Another idea would be to avoid bfd_get_mtime entirely in gdb.  I don't
know how feasible this is, given that (I think) we need it to call
through the iovec.

Maybe gdb could *only* use bfd_get_mtime when it matters.  This would
mean changing gdb_bfd_open to create a BFD before checking the cache,
but maybe that's not very expensive.

I'd appreciate your thoughts on the topic.

Tom