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

[Hannes Domani via gdb-patches]

 Am Dienstag, 14. Januar 2020, 17:57:10 MEZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >> 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.

I reported this issue some time ago:
https://sourceware.org/bugzilla/show_bug.cgi?id=25302