From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4F7C2395CC89 for ; Thu, 18 Jun 2020 15:04:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F7C2395CC89 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:41909) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jlw5R-0000D1-0q; Thu, 18 Jun 2020 11:04:17 -0400 Received: from [176.228.60.248] (port=4278 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jlw5Q-0005SU-Dh; Thu, 18 Jun 2020 11:04:16 -0400 Date: Thu, 18 Jun 2020 18:04:01 +0300 Message-Id: <83r1ucza8u.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey Cc: tromey@adacore.com, gdb-patches@sourceware.org, palves@redhat.com In-Reply-To: <87k1044g1x.fsf@tromey.com> (message from Tom Tromey on Thu, 18 Jun 2020 08:14:18 -0600) 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> <87k1044g1x.fsf@tromey.com> X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 15:04:19 -0000 > From: Tom Tromey > Cc: Tom Tromey , gdb-patches@sourceware.org, > Pedro Alves > Date: Thu, 18 Jun 2020 08:14:18 -0600 > > Eli> There's one more potential issue with Gnulib's replacement of 'fstat': > Eli> it also replaces the definition of 'struct stat', and it does that in > Eli> a way that might yield incompatibility between the definition on > Eli> the system header and Gnulib's sys/stat.h replacement. > > I am looking into this issue again for the upcoming gdb 10 release. > > Looking at the gnulib in the gdb tree, as far as I can tell, it doesn't > actually override struct stat. The code is all there: > > /* Optionally, override 'struct stat' on native Windows. */ > #if @GNULIB_OVERRIDES_STRUCT_STAT@ > [...] > > ... however, this is only ever set to 0 in our tree: > > $ git grep 'GNULIB_OVERRIDES_STRUCT_STAT.*=' -- gnulib/import/ > gnulib/import/Makefile.in:GNULIB_OVERRIDES_STRUCT_STAT = @GNULIB_OVERRIDES_STRUCT_STAT@ > gnulib/import/m4/sys_stat_h.m4: GNULIB_OVERRIDES_STRUCT_STAT=0; AC_SUBST([GNULIB_OVERRIDES_STRUCT_STAT]) > > (I chose a tighter grep for the purposes of posting, but in reality I > looked at all mentions of GNULIB_OVERRIDES_STRUCT_STAT.) > > So, I think this is maybe not an issue. I meant a different part of Gnulib's sys/stat.h: /* Large File Support on native Windows. */ #if @WINDOWS_64_BIT_ST_SIZE@ # define stat _stati64 #endif This will also redirect 'struct stat' to 'struct _stati64', which has a 64-bit st_size and a 64-bit st_mtime (and other times) members. And by default @WINDOWS_64_BIT_ST_SIZE@ evaluates to 1 in the MinGW build. This might not be a problem when building with MinGW64, but my GDB builds are 32-bit, and I want to use the default version of 'struct stat', where both the st_size and the time-related members are 32-bit wide. Therefore, I had a problem with the above redirection. In case you need to refresh your memory, I explained all that in more detail here: https://sourceware.org/pipermail/gdb-patches/2020-January/164882.html > The timezone thing, however, remains an issue. It seems dangerous to me > that we would have two implementations of stat that would give different > answers. It's too easy, IMO, to accidentally compare values from one > with values from the other -- in fact, that's what lead to the patches > in this thread I'm replying to. I agree. > Based on this, my inclination is to patch our copy of gnulib to avoid > replacing stat on Windows. I'm looking into how to do this. AFAICT, gnulib/import/m4/stat.m4 does that for MinGW unconditionally: case "$host_os" in mingw*) dnl On this platform, the original stat() returns st_atime, st_mtime, dnl st_ctime values that are affected by the time zone. REPLACE_STAT=1 ;; So the way to avoid the replacement is to modify this test, right? Thanks.