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

Tom Tromey
2020-01-14T16:57:02Z

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