From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73957 invoked by alias); 20 Jan 2020 17:29:13 -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 73949 invoked by uid 89); 20 Jan 2020 17:29:12 -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=H*r:sk:fencepo, H*r:4.82, H*r:sk:RSA_AES 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; Mon, 20 Jan 2020 17:29:02 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1itarC-0004KT-Sw; Mon, 20 Jan 2020 12:28:59 -0500 Received: from [176.228.60.248] (port=4537 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1itar2-0004DA-U4; Mon, 20 Jan 2020 12:28:52 -0500 Date: Mon, 20 Jan 2020 20:50:00 -0000 Message-Id: <8336caxciw.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 Mon, 20 Jan 2020 15:48:22 +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> 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/msg00612.txt.bz2 > Cc: cbiesinger@google.com, gdb-patches@sourceware.org > From: Pedro Alves > 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 > > #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.