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

[Eli Zaretskii <eliz@gnu.org>]

> From: Tom Tromey <tom@tromey.com>
> CC: Simon Marchi <simon.marchi@polymtl.ca>,  gdb-patches@sourceware.org,  palves@redhat.com
> Date: Tue, 14 Jan 2020 09:56:46 -0700
> 
>     (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.

Been there, done that, have scars to prove.

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

Regardless of what we do about this particular issue, maybe you could
report this to bug-gnulib, as one more evidence how redefining 'stat'
in Gnulib causes problems.  Because my report about a similar problem,
here:

  https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00205.html

didn't convince the Gnulib developers.

Thanks.