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 ED33A386F41E for ; Fri, 14 Aug 2020 23:40:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ED33A386F41E 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 B687D5638B; Fri, 14 Aug 2020 19:40:05 -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 0UVsUJQpa3q2; Fri, 14 Aug 2020 19:40:05 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6C64556388; Fri, 14 Aug 2020 19:40:05 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A9A12833BE; Fri, 14 Aug 2020 16:40:03 -0700 (PDT) Date: Fri, 14 Aug 2020 16:40:03 -0700 From: Joel Brobecker To: Tom de Vries Cc: Tom Tromey , Pedro Alves via Gdb-patches , Pedro Alves Subject: Re: [PATCH 2/3] Consistently use BFD's time Message-ID: <20200814234003.GA27502@adacore.com> References: <87wo442wjq.fsf@tromey.com> <83o8pgz3lv.fsf@gnu.org> <83k104z2cb.fsf@gnu.org> <0b80b7da-d9f8-d517-920d-60572134096e@redhat.com> <87a70zvv6o.fsf@tromey.com> <87k102vm5y.fsf@tromey.com> <07179329-a5ac-6947-7303-c0d7b919aa39@redhat.com> <87ime74eta.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, 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: Fri, 14 Aug 2020 23:40:07 -0000 > > Pedro> Can you clarify what do you see not work? I tried rebasing it > > Pedro> here, and it seems to work. It builds cleanly on GNU/Linux and > > Pedro> mingw32-w64 (both -m64 and -m32). I've pasted the resulting patch below. > > > > What if we apply this patch, but also apply a patch to our gnulib to > > avoid the timezone offsetting? We kept the code in > > gnulib/update-gnulib.sh to make this pretty easy to do, and we could try > > to work with upstream gnulib to make this feature optional (hopefully > > eliminating the need for our patch). > > > > This would avoid the mtime comparison problem. I don't know how to > > solve that another way, at least not without changing BFD to also use > > gnulib -- which seems to come with its own risks. > > > > Once we solve this somehow, I can rebase and update the original series > > here. > > > > This is one of the final blockers to the 10.1 branch, so it would be > > good to reach some kind of resolution soon. > > > > Hi, > > [ it's been a bit more that two weeks since the last email on this, so > I'm pinging this. ] > > Joel wrote as summary here ( > https://sourceware.org/pipermail/gdb-patches/2020-August/171176.html ) : > ... > Hannes proposed, as a workaround, a hack involving > undefining/redefining the fstat macro. The way it was proposed > is not stricly portable as I understand it (it uses an extension), > so we wouldn't be able to use it as is. But I'm starting to > warm to the idea of doing something like that on the branch, > while we take the time we need to discuss the proper approach. > ... > > Is there any indication by now which way we want to go with this for the > 10.1 branch? For the short-term solution, I think the best compromise is to patch gnulib like Tom suggests. We have the infrastructure to do that and maintain the patch for as long as it takes to discuss the proper solution (personally, I think the only way forward for the better solution will require a live discussion; I am happy to help set that up if people would find it useful). Please let us know if you guys think there is a better short term solution. Otherwise, let's ask Tom to submit a patch that patches gnulib, and start creating the GDB 10 pre-release. -- Joel