Re: [PATCH 2/3] Consistently use BFD's time

[Eli Zaretskii <eliz@gnu.org>]

> Cc: cbiesinger@google.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Mon, 20 Jan 2020 15:48:22 +0000
> 
> > I guess this means some other Gnulib module pulls in 'stat', in which
> > case --avoid=stat is the way to try to avoid it, yes.  (My guess is
> > that the 'largefile' module causes 'stat' to be pulled in.)
> 
> I'm not sure about that solution -- won't --avoid=stat mean that
> we disable any stat gnulib fix for all platforms, instead of just
> for Windows?

It would, but do we have any known problems with stat and fstat on
other platforms?

> We only have one lstat call, but we also use fstat, for example, and
> I assume that these *stat modules in gnulib are all intertwined.
> Also, we may only have one lstat call nowadays, but who knows about
> the future.

Even having a gdb_lstat for that purpose will be simpler and more
future-proof than the whole Gnulib stat module, I think.

> I did come up with a workaround though, it's just different.
> 
> I noticed that gnulib's sys/stat.h replacement starts with a way to
> bypass it:
> 
>  #if defined __need_system_sys_stat_h
>  /* Special invocation convention.  */
> 
>  #include_next <sys/stat.h>
> 
>  #else
>  /* Normal invocation convention.  */
> 
>  #ifndef _GL_SYS_STAT_H
> 
> So I think we can take advantage of that to be able to make sure that
> when we include "bfd.h", its functions are declared using the system's
> stat, which is the same version that bfd is built against.

But stat/fstat the functions will still shadow the system ones, would
they not?  And if they would, doesn't it mean subtle bugs where, e.g.,
the Gnulib replacement implementations rely on wide-enough st_size,
for example, or st_mtime?

Also, aren't some of the problems on platforms other than MinGW
resolved by the Gnulib sys/stat.h header, as opposed to the
replacement implementation of the functions themselves?

Thanks.