From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115924 invoked by alias); 21 Jan 2020 17:56:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 115912 invoked by uid 89); 21 Jan 2020 17:56:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=satisfactory, forces, U*palves, sk:palves X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2020 17:56:44 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1itxla-0008WL-57; Tue, 21 Jan 2020 12:56:42 -0500 Received: from [176.228.60.248] (port=2419 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1itxlZ-0002f9-AZ; Tue, 21 Jan 2020 12:56:41 -0500 Date: Tue, 21 Jan 2020 19:38:00 -0000 Message-Id: <83v9p4vgkd.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tromey@adacore.com, cbiesinger@google.com, gdb-patches@sourceware.org In-reply-to: (message from Pedro Alves on Tue, 21 Jan 2020 13:47:28 +0000) Subject: Re: [PATCH 2/3] Consistently use BFD's time References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> <83d0bi348d.fsf@gnu.org> <871rrygco6.fsf@tromey.com> <874kwteraa.fsf@tromey.com> <83v9p919hy.fsf@gnu.org> <8336caxciw.fsf@gnu.org> <40fa6532-4440-d47b-63db-9485828c791f@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00643.txt.bz2 > Cc: tromey@adacore.com, cbiesinger@google.com, gdb-patches@sourceware.org > From: Pedro Alves > 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.