From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26194 invoked by alias); 16 Jan 2020 20:47:38 -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 26145 invoked by uid 89); 16 Jan 2020 20:47:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:209.85.167.196, H*RU:209.85.167.196, HX-HELO:sk:mail-oi X-HELO: mail-oi1-f196.google.com Received: from mail-oi1-f196.google.com (HELO mail-oi1-f196.google.com) (209.85.167.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 20:47:31 +0000 Received: by mail-oi1-f196.google.com with SMTP id k4so20171155oik.2 for ; Thu, 16 Jan 2020 12:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mQbbPM1ienmvMlF5XGC9zSsnWHf9iS6m4Vp6ppZQOoo=; b=ijY8Q4Mvucb3NEcA/QWk/W+BDbE/pyUVamaYVEufSgcN+zhiUB80APhTx6IPjp8lt2 ozfpJ7X85sAXtJE+QcoElkDQV3eB7RIz46dLShAghDu2ARRDnzUPNx79JJ6C4eAyNHAs BHwJUxQZI1mlV4BZw/d+5EeR+J6/rdJNdYXqgctw9JI08lxV94XOodVwPCBuNN7QXPXF 2ByC9yVecumyL89H2RG9TBVEiqy9/fBjC4DZ+Lj8WA40D98U3r7vAVlaI89Hvb45xqK/ ZC7aDagWu5V0NbukiWTltrSzFIXPUk1Hb6l68Rqqqs3hwUksZETrp7jJ/mUzIBszY3j/ WCxA== MIME-Version: 1.0 References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> In-Reply-To: From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Thu, 16 Jan 2020 21:58:00 -0000 Message-ID: Subject: Re: [PATCH 2/3] Consistently use BFD's time To: Pedro Alves Cc: Eli Zaretskii , Tom Tromey , gdb-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00468.txt.bz2 On Thu, Jan 16, 2020 at 3:37 PM Pedro Alves wrote: > > On 1/15/20 4:07 PM, Eli Zaretskii wrote: > >> From: Tom Tromey > >> Cc: Tom Tromey > >> Date: Tue, 14 Jan 2020 14:09:55 -0700 > >> > >> gdb uses the gnulib stat, while BFD does not. This can lead to > >> inconsistencies between the two, because the gnulib stat adjusts for > >> timezones. > > > > There's one more potential issue with Gnulib's replacement of 'fstat': > > it also replaces the definition of 'struct stat', and it does that in > > a way that might yield incompatibility between the definition on > > the system header and Gnulib's sys/stat.h replacement. > > If gdb_bfd.c uses the Gnulib definition of 'struct stat' (as I think > > we do everywhere in gdb/), then this replacement might create problems > > on MinGW similar to those I reported to the Gnulib list (see the URL I > > cited in an earlier message), because bfd_stat uses an incompatible > > definition of 'struct stat'. > > > > Of course, given that the Gnulib developers rejected my request not to > > override the system definition of 'struct stat', GDB could also ignore > > those problems, accepting their judgment. > > I think that we need to: > > - #undef stat before including bfd headers. > - Redefine it afterwards back to rpl_stat (*) > - add some kind of wrapper around bfd_stat (like maybe called gdb_bfd_stat) Wouldn't it be easier to #define GNULIB_NAMESPACE in this file? That way, the gnulib stuff stays in gnulib:: (or gdb::, or whatever), and the global ::stat is the system one. > that handles the mismatch. Something like: > > int > gdb_bfd_stat (bfd *abfd, struct stat *statbuf) > { > #undef stat > struct stat st; > > int res = bfd_stat (abfd, &st); > if (res != 0) > return res; > > #define COPY(FIELD) statbuf->FIELD = st.FIELD > COPY (st_dev); > // ... copy over all relevant fields ... > #undef COPY > > #define stat rpl_stat > } > > (*) there's probably some '#ifdef _GL...' we can check to know > whether we need to do this. > > Thanks, > Pedro Alves >