From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id DE6DB3840C23 for ; Fri, 19 Jun 2020 12:02:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DE6DB3840C23 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-393-uQlrdzC6NYqG5yFLe_dGVA-1; Fri, 19 Jun 2020 08:02:31 -0400 X-MC-Unique: uQlrdzC6NYqG5yFLe_dGVA-1 Received: by mail-wm1-f71.google.com with SMTP id c66so3898937wma.8 for ; Fri, 19 Jun 2020 05:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wCFB+01BfabtsYaik6T6PtGL0pS1yv7SxbjXGceixsQ=; b=ZSg0At/4xW/3cCeLK14cmJLUEzErbZ+6NVNxtX6enyJpLxkIDQDvgnv7gu9pxoFWyZ XBr/MBBK4oNeV3NOGltPL/JM/0CIX9sDEIRS+wqrDCY206+QfbwKpqThn/rHhbjdBuqf rp/tXdF5oSOOJtv10DkDCAMow6BauhkTIste2L9DCtF/FStlEh+xI9DpVDR5QwjoQW9o CHB6sHwg0ROIC4aU8N0QJTkWTxh8TZC+tABBgb9U2xWFn5/TXWbErolbrrpNI5W7sJ2A bqn8b+Gveflln8p8zw067nqXSI7damt3s6wXegHnoRlel978j/DB5J3nBdR2DvIClEA8 +FKg== X-Gm-Message-State: AOAM533LjQJil3jXvTu+b0m2jx7s0gNIrNybHpOwr/z+KluuyI4VY4zk s8gFKi8ar0fnmDHF4HwMN1YwW5QRD44nTcWhD+7rkCzLjWgHAcWeKay9yUfKmQo+yeB0Omxe+Pl k6QVwOhgd5d+5b9vxJlxTBw== X-Received: by 2002:a5d:684a:: with SMTP id o10mr3554826wrw.4.1592568149928; Fri, 19 Jun 2020 05:02:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydng2H2SJKUjaoNFJIT6rxb9X3ryOCv9Jvx3IWe5xV7bhllTrAqd6oQCFYymQGD4a6S6q/4g== X-Received: by 2002:a5d:684a:: with SMTP id o10mr3554816wrw.4.1592568149740; Fri, 19 Jun 2020 05:02:29 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id s18sm7995207wra.85.2020.06.19.05.02.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 05:02:29 -0700 (PDT) Subject: Re: [PATCH 2/3] Consistently use BFD's time To: Eli Zaretskii References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> <87k1044g1x.fsf@tromey.com> <83r1ucza8u.fsf@gnu.org> <87wo442wjq.fsf@tromey.com> <83o8pgz3lv.fsf@gnu.org> <83k104z2cb.fsf@gnu.org> Cc: tom@tromey.com, tromey@adacore.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0b80b7da-d9f8-d517-920d-60572134096e@redhat.com> Date: Fri, 19 Jun 2020 13:02:28 +0100 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: <83k104z2cb.fsf@gnu.org> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Fri, 19 Jun 2020 12:02:36 -0000 On 6/18/20 6:54 PM, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org, tromey@adacore.com >> From: Pedro Alves >> Date: Thu, 18 Jun 2020 18:32:42 +0100 >> >>>> 2. Use --avoid=stat --avoid=fstat. So far this seems like the best >>>> approach. Pedro pointed out that this means we won't get any gnulib >>>> fixes for other bugs in this area. However, given gdb's relatively >>>> minimal needs from stat, and given the fact that gnulib is >>>> introducing other bugs, this seems like an acceptable tradeoff to me. >>> >>> If that works, I think it's an okay solution. >> >> I disagree. It's not only GDB's stat usage that counts, it's the >> other gnulib modules that depend on the stat module fixes too. Also, >> that approach disables the stat module for all systems, not just >> mingw. I think it's just bad policy to disable a module like that. > > What would you suggest instead? > I had presented two different ways forward back when this was originally discussed: [Handle different "struct stat" between GDB and BFD] [users/palves/stat branch] https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00608.html [use gnulib --avoid=largefile, let ACX_LARGEFILE handle enabling largefile support consistently throughout the tree] [users/palves/gnulib-largefile branch] https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00637.html Back then IIRC, I was thinking that the --avoid=largefile solution was the best one, but for some reason, the gnulib build fails with that, which seemed like a gnulib bug. Since you then said back then you didn't really care for a solution to this problem, I ended up forgetting about this whole issue and many of the details. :-/ Thanks, Pedro Alves