From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 1D8603851C12 for ; Thu, 18 Jun 2020 17:57:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1D8603851C12 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D7C96117FBE; Thu, 18 Jun 2020 13:57:30 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0lwtbH5+2l39; Thu, 18 Jun 2020 13:57:30 -0400 (EDT) Received: from murgatroyd (174-16-104-48.hlrn.qwest.net [174.16.104.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id 5F3D2117FA7; Thu, 18 Jun 2020 13:57:30 -0400 (EDT) From: Tom Tromey To: Pedro Alves Cc: Eli Zaretskii , Tom Tromey , gdb-patches@sourceware.org, tromey@adacore.com 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> <83r1ucza8u.fsf@gnu.org> <87wo442wjq.fsf@tromey.com> <83o8pgz3lv.fsf@gnu.org> X-Attribution: Tom Date: Thu, 18 Jun 2020 11:57:29 -0600 In-Reply-To: (Pedro Alves's message of "Thu, 18 Jun 2020 18:32:42 +0100") Message-ID: <878sgk2r5i.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 17:57:32 -0000 Pedro> I disagree. It's not only GDB's stat usage that counts, it's the Pedro> other gnulib modules that depend on the stat module fixes too. Also, Pedro> that approach disables the stat module for all systems, not just Pedro> mingw. I think it's just bad policy to disable a module like that. The reason I came to this conclusion is that the list of fixes doesn't seem to include anything super important; while using it introduces bugs that are difficult to work around, or even audit for. In particular, we'll have to be careful to never compare mtime-from-gnulib against mtime-from-BFD. Here's the list from the version of gnulib we're using. Portability problems fixed by Gnulib: * On platforms where 'off_t' is a 32-bit type, 'stat' may not correctly report the size of files or block devices larger than 2 GB. (Cf. 'AC_SYS_LARGEFILE'.) * On Linux/x86 and Linux/x86_64, applications compiled in 32-bit mode cannot access files that happen to have a 64-bit inode number. This can occur with file systems such as XFS (typically on large disks) and NFS. (Cf. 'AC_SYS_LARGEFILE'.) * The 'st_atime', 'st_ctime', 'st_mtime' fields are affected by the current time zone and by the DST flag of the current time zone on some platforms: mingw, MSVC 14 (when the environment variable 'TZ' is set). * On MSVC 14, this function fails with error 'ENOENT' on files such as 'C:\pagefile.sys' and on directories such as 'C:\System Volume Information'. * On some platforms, 'stat("link-to-file/",buf)' succeeds instead of failing with 'ENOTDIR'. FreeBSD 7.2, AIX 7.1, Solaris 9, mingw64. * On some platforms, 'stat(".",buf)' and 'stat("./",buf)' give different results: mingw, MSVC 14. * On Solaris 11.4, when this function yields a timestamp with a nonpositive 'tv_sec' value, 'tv_nsec' might be in the range -1000000000..-1, representing a negative nanoseconds offset from 'tv_sec'. I think the first one is probably not important to gdb; the second is already working; and the third is a bug. The rest just don't seem very relevant. Tom