From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104324 invoked by alias); 10 Aug 2017 22:04:10 -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 104276 invoked by uid 89); 10 Aug 2017 22:04:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:static., HContent-Transfer-Encoding:8bit X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-io0-f195.google.com Received: from mail-io0-f195.google.com (HELO mail-io0-f195.google.com) (209.85.223.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 22:04:07 +0000 Received: by mail-io0-f195.google.com with SMTP id o9so2401536iod.5; Thu, 10 Aug 2017 15:04:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=4PS8QoxEJvQFxoluOvJzu42WE/6oITWtMj1Sx4DY/Pg=; b=HS3qzkay9jQDY/VdIlXwU9rC4DDRkGx0IAuUSI1DUgM7/+Q5MTbHtdgG4fa1haAsRg uCr95qmOxDjQSwfrNTDjpcf3wZy12lFiuLQm1tbXo02KM8yBULQFLSMBWv3SoGr/RvFG /U3bgfO0OZovfCAOekqANBRUnhO+8b/MRacFs1YCGQNy8cHjttp/hk/cbHkEu+H84XAl UgCHl+ebVl5SYD4K2ElWofPiEH3cvk2IsPzrLcFVKwzSbeat/jUGao/QCVqK0aWioQCM YHf33gVLPM38P1ZNy+J9rw83W7mZR+f42RIGWgFE/wMu/7wNNvitd4aIBLs6TFDLtztu dRfQ== X-Gm-Message-State: AIVw11261k/j/ZWQ1/R9hSORHwND/utI3tQ7b9qIc1YordY5MzuU2Xxi fwce64ZUs0q2IQ== X-Received: by 10.107.173.206 with SMTP id m75mr12163958ioo.152.1502402646043; Thu, 10 Aug 2017 15:04:06 -0700 (PDT) Received: from 1170ee0b50d5 (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id o64sm3513512ioi.16.2017.08.10.15.04.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 15:04:05 -0700 (PDT) Date: Thu, 10 Aug 2017 22:04:00 -0000 From: Yao Qi To: Pedro Alves Cc: Jiong Wang , GDB , Binutils Subject: Re: [AArch64][6/6] Core file support for "pauth" feature Message-ID: <20170810220402.GF8039@1170ee0b50d5> References: <20170810212238.GE8039@1170ee0b50d5> <26b4881d-bec9-e2a6-fe96-13f2a44f7b1f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26b4881d-bec9-e2a6-fe96-13f2a44f7b1f@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00225.txt.bz2 On 17-08-10 22:32:40, Pedro Alves wrote: > > I think there's a misunderstanding. It's not about clarity -- if HWCAP_APIA > is defined on a !Aarch64 host as some value other than "(1 << 16)", then > this: > > > +++ b/gdb/aarch64-linux-tdep.c > > > > - return tdesc_aarch64; > > + return aarch64_hwcap & HWCAP_APIA ? tdesc_aarch64_pauth : tdesc_aarch64; > > } > > will silently compile to use wrong value. > > Might never happen in practice, but why write a potential problem, > _particularly since you already have to write the fallback > macro anyway_? What's the advantage of not doing what I suggested? I want the macro name sync'ed with kernel. However I understand your point. Let me see if I can ask kernel people change it to HWCAP_ARM64_APIA, or something else. Kernel patches are not merged yet, as far I as know. -- Yao (齐尧)