From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16489 invoked by alias); 16 Jan 2020 20:37:51 -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 16475 invoked by uid 89); 16 Jan 2020 20:37:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Gnulibs, Gnulib's, Gnulib, cited X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 20:37:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579207057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N0bLAj656w0q65pNy+l7SEd2NlUwLOtLBX0JDugVDB4=; b=Ek6BTz3A0fSRwBvFEoIgYkQhlml2lIncjJcwKkiejrH+A+3lZ5MrPmwgNr/ldk5C+f1gLB gcxTF3kxiA/dhHE9a68LM/JGXSnHIWU27WgT12+xKUZqcHYNvowz9GfxdFOstgXGwDFvCD bxc7p0D91F5ioPp2Slgl9CYyB2m/Deg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-N1Gw5080P62t940pVet79A-1; Thu, 16 Jan 2020 15:37:31 -0500 Received: by mail-wr1-f72.google.com with SMTP id y7so9690642wrm.3 for ; Thu, 16 Jan 2020 12:37:31 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id l17sm29530348wro.77.2020.01.16.12.37.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 12:37:29 -0800 (PST) Subject: Re: [PATCH 2/3] Consistently use BFD's time To: Eli Zaretskii , Tom Tromey References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 16 Jan 2020 20:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <83wo9s4sac.fsf@gnu.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00467.txt.bz2 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) 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