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

Eli Zaretskii
2020-01-14T19:46:41Z

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