From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50072 invoked by alias); 16 Jan 2020 21:58:55 -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 50064 invoked by uid 89); 16 Jan 2020 21:58:55 -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= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 21:58:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579211931; 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=2OLnXV44k6jdaNS7DnSN1u7zBey4awYrId1wrzKETMI=; b=iIP3piqZPEJ6S1u6vC49mU16uz81LfAtB42iVzs9zrT4dF1ahntMB61kQj3OaQnEtWJjKf F3+9W1UyaLKpU8d1iTMyodHqHLUlTCn8AIlR56IoPpJhmbjDJFnHLb8qodnD7NPTlrQuhK BWRSTI5KTifd80952VyYpVMMUynPl9E= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-NlRTbLKWNJSneT_Sj_wAmw-1; Thu, 16 Jan 2020 16:58:50 -0500 Received: by mail-wr1-f70.google.com with SMTP id i9so9712648wru.1 for ; Thu, 16 Jan 2020 13:58:50 -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 z83sm265085wmg.2.2020.01.16.13.58.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 13:58:48 -0800 (PST) Subject: Re: [PATCH 2/3] Consistently use BFD's time To: Christian Biesinger References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> Cc: Eli Zaretskii , Tom Tromey , gdb-patches From: Pedro Alves Message-ID: <97102dda-3d66-4466-4df9-10ad3145ffbf@redhat.com> Date: Thu, 16 Jan 2020 22:31: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: 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/msg00469.txt.bz2 On 1/16/20 8:46 PM, Christian Biesinger via gdb-patches wrote: > On Thu, Jan 16, 2020 at 3:37 PM Pedro Alves wrote: >> 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. Good idea. I suspect it's better to do it in an isolated file than in the whole symfile.c of whatever the problem was found, so that we don't have to sprinkle the namespace prefix around. I.e., in a file that only implements gdb_bfd_stat. At least, until have use a namespace everywhere. We could also poison bfd_stat so that we're sure nothing in gdb uses it other than the wrapper. Thanks, Pedro Alves