From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120261 invoked by alias); 18 Jan 2020 07:58:39 -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 120253 invoked by uid 89); 18 Jan 2020 07:58:38 -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=symfile.c, UD:symfile.c, symfilec 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; Sat, 18 Jan 2020 07:58:37 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1isj06-00046N-PY; Sat, 18 Jan 2020 02:58:34 -0500 Received: from [176.228.60.248] (port=1057 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1isj05-00060G-70; Sat, 18 Jan 2020 02:58:33 -0500 Date: Sat, 18 Jan 2020 11:07:00 -0000 Message-Id: <83v9p919hy.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: cbiesinger@google.com, palves@redhat.com, gdb-patches@sourceware.org In-reply-to: <874kwteraa.fsf@tromey.com> (message from Tom Tromey on Fri, 17 Jan 2020 13:55:57 -0700) 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> 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/msg00571.txt.bz2 > From: Tom Tromey > Cc: Eli Zaretskii , Christian Biesinger , palves@redhat.com, gdb-patches@sourceware.org > Date: Fri, 17 Jan 2020 13:55:57 -0700 > > >>>>> "Tom" == Tom Tromey writes: > > >>>>> "Eli" == Eli Zaretskii writes: > Eli> I wonder whether a better way is not to import the Gnulib 'stat' and > Eli> 'fstat' modules at all. Are they required by other Gnulib modules, > Eli> and if so, by which ones? > > Tom> I am wondering this as well. While I think we can track down the bad > Tom> spots -- either calling the "wrong" stat or incorrectly comparing values > Tom> from the different stats (the patches I sent probably accomplish the > Tom> latter already) -- it seems fragile to rely on this. > > It came in originally in a patch I sent and one that Yao sent: > > https://sourceware.org/ml/gdb-patches/2013-11/msg00502.html This one removed gdb_stat.h, which had replacements for the S_IS* macros, something that should be easy to bring back, and doesn't really justify replacing the functions and the struct's themselves. > https://sourceware.org/ml/gdb-patches/2014-11/msg00654.html This seems to be about using 'lstat' freely. But I see only one call to 'lstat' in our sources -- in symfile.c. So maybe having our own replacement, or even calling 'lstat' conditioned by an #ifdef, would be a good-enough solution. > I thought maybe removing these workarounds would be ok, but it seems > like it can't be done: when I remove stat and lstat from > update-gnulib.sh, they still appear. > > Maybe --avoid=stat will work. 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.)