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

[Eli Zaretskii]

> Cc: tromey@adacore.com, cbiesinger@google.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 21 Jan 2020 13:47:28 +0000
> 
> On 1/20/20 8:50 PM, Pedro Alves wrote:
> 
> > So if BFD is compiled with _FILE_OFFSET_BITS == 64 and
> > _USE_32BIT_TIME_T is not defined, the mismatch ends up going
> > away?  Is there a reason we _wouldn't_ want to enable largefile
> > support in bfd?
> 
> I'm looking at this some more, and am trying to understand
> what is really going on.  I can't seem to reproduce your original
> issue, I think because I'm using (32-bit) mingw-w64, while the issue
> with 32-bit size_t happen on (32-bit) mingw.org instead.  Correct?

It isn't only st_size, it's also the width of the st_?time fields.

> So maybe the best to do here is to import gnulib with 
> --avoid=largefile, and let the ACX_LARGEFILE in gnulib/'s
> top configure handle the enabling largefile support in sync
> with all other top level dirs.  I tried that,
> and confirmed that _FILE_OFFSET_BITS=64 still ends up in
> gnulib's config.h.  The build then fails inside gnulib
> for me on 32-bit mingw-w64, maybe there's a bug that needs
> to be fixed, but I'd think this _should_ work.

AFAIU, largefile is intentionally requested in all MinGW builds, the
Gnulib developers explicitly said that was their intent.  And
largefile then causes the replacement of st_size etc. in struct stat,
for consistency.  MinGW64 doesn't need all that stuff at all, because
their defaults are already set to use 64-bit st_size and 64-bit time_t
fields.  That's because MinGW64 tossed support for Windows version
before Vista long ago, and therefore the incompatible changes
Microsoft introduced into MSVCRT.DLL from Vista onwards are of no
importance for MinGW64 (and the fragment from their stat.h you've
shown is by now just useless ballast that is AFAIU never used in
MinGW64).

But mingw.org's MinGW still supports the older Windows versions, and
the only sane way of doing that is to use 32-bit time_t, which
basically means one needs to use the regular implementation of stat,
not _stati64 or any other variety.  Moreover, using _stati64 instead
of stat, as MinGW64 does by default (and Gnulib forces the same on any
other MinGW build), is a non-starter for me, because _stati64 didn't
exist before Vista.  So a GDB built that way will simply refuse to run
on any older system, even if you build it on a Windows box that does
have _stati64.

Having said all that, let me explicitly say that I don't want to put a
drag on GDB development, and therefore will not insist that solutions
for this kind of problems must compile cleanly with my MinGW
toolchain.  That is why I never bothered to say anything here about
the struct stat problem, and only posted that to the Gnulib list.  I
know how to hack the build to make it DTRT for mingw.org's MinGW; I
did that with the pretest, as soon as I found out the reason for the
breakage (in a nutshell, remote debugging with gdbserver was
completely broken: GDB would crash as soon as you run the remote
target).  As long as the problem was limited to mingw.org's MinGW, I
kept silence here, and only broke that silence because Tom uncovered
what seems to be a similar problem, but one that affects MinGW64 as
well.

Bottom line: if you have a satisfactory solution for MinGW64, go for
it regardless of what it will mean for the MinGW I use; I don't want
to complicate this stuff any more than it already is, given that the
Gnulib developers rejected what I consider the simplest and the most
reliable solution (which would have seamlessly satisfied both
varieties of MinGW).  Now that I'm aware of the problems with the
Gnulib stat replacements, I can work around that very easily.

Thanks.