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 4CF54384A40A for ; Wed, 2 Sep 2020 14:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4CF54384A40A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 210F9116F19; Wed, 2 Sep 2020 10:59:45 -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 bRDyyRGxqVMK; Wed, 2 Sep 2020 10:59:45 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9EB78116EA0; Wed, 2 Sep 2020 10:59:44 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D38CC82D7D; Wed, 2 Sep 2020 07:59:42 -0700 (PDT) Date: Wed, 2 Sep 2020 07:59:42 -0700 From: Joel Brobecker To: Tom Tromey Cc: Pedro Alves , Pedro Alves via Gdb-patches , Tom Tromey Subject: Re: [PATCH 2/3] Consistently use BFD's time Message-ID: <20200902145942.GE24789@adacore.com> References: <87a70zvv6o.fsf@tromey.com> <87k102vm5y.fsf@tromey.com> <07179329-a5ac-6947-7303-c0d7b919aa39@redhat.com> <87ime74eta.fsf@tromey.com> <20200814234003.GA27502@adacore.com> <20200823160944.GA14567@adacore.com> <8548d40d-cf0f-482c-85d2-cfec7585d13f@palves.net> <20200824200440.GK24789@adacore.com> <87h7sgz17f.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h7sgz17f.fsf@tromey.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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: Wed, 02 Sep 2020 14:59:46 -0000 > Joel> I think our only realistic options are to take a more radical approach, > Joel> either: > > Joel> - Stop using the stat module from gnulib (which I think we said > Joel> we want to keep); or > > Joel> - Patch the gnulib implementation for now to block the incompatible > Joel> behavior. > [...] > Joel> - Something else? > > One remaining option is to change BFD to use gnulib as well. > > This is workable as long as gdb never tries to use an out-of-tree > library that uses struct stat (or a stat-derived time_t) as part of its > API. To my knowledge gdb is currently safe on this front. I'd guess it > seems likely to remain safe too, though of course one can't be certain. Indeed. IIRC, this is something that was briefly discussed with the binutils team. They were open to the idea, but on the other hand, I think they needed a bit more information about the expected gains they could hope for. We can pursue this again with them if we'd like and we think this could be decided and implemented relatively quickly. My feeling is that this is not a trivial move, and thus would deserve a bit of discussion before moving forward. Doing that just before we branch seems a bit riskier. Perhaps we could first go with the local gnulib patch, and then discuss with binutils about them adopting gnulib. PS: Do we have an idea how binutils depending on gnulib might affect binutils standalone distribution (e.g. the binutils libs provided by the various distros)? -- Joel