From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121156 invoked by alias); 10 Aug 2017 21:22:46 -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 121134 invoked by uid 89); 10 Aug 2017 21:22:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=170810, 17-08-10, Hx-languages-length:1084, inclined X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-io0-f196.google.com Received: from mail-io0-f196.google.com (HELO mail-io0-f196.google.com) (209.85.223.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 21:22:43 +0000 Received: by mail-io0-f196.google.com with SMTP id o9so2345257iod.5; Thu, 10 Aug 2017 14:22:42 -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=NdVKl0aIPQqqQhLTdrsDI0c1b2qiuUwV5NZsoFl8I/Q=; b=HOaFfx41AY7gD42p70TjKMpzyIGsfnudnQAHpldmrmtTbwr9M+276qe8/My45bYY4M iG3sXgJT4RupzYqjYccV87vAQ6k515sUSkX8iOIMpOZkG2vK9WiwdVey8xlg1WC+8oO2 CRFiZXVL/Rs69k9xddBY9yS7hV9eO+SK9wBWjUDfdr+i34X9lydCccZlca04I+mKfwua CcuU2odaGoMT+AIavsvv7vZV4VFEDpB84PJj4hbmFci44Dwd48N5SGkl0Zke548oCWdD VzkfVXgZQyI9orDR5StvgEqdlNDnSg45vdSTDZk7z7BnQIbvCLhFLZF+kp6118hnKUIj 4ADw== X-Gm-Message-State: AIVw111vDmaIm6nW57BFlebWkMnssip8f6go1jdUOB6XzeANOjNjAhmT an8WRYM8WFQP+w== X-Received: by 10.107.179.135 with SMTP id c129mr11262532iof.106.1502400161521; Thu, 10 Aug 2017 14:22:41 -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 b203sm3462225iob.47.2017.08.10.14.22.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 14:22:41 -0700 (PDT) Date: Thu, 10 Aug 2017 21:22: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: <20170810212238.GE8039@1170ee0b50d5> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00223.txt.bz2 On 17-08-10 12:08:36, Pedro Alves wrote: > > +#ifndef HWCAP_APIA > > +/* AArch64 GNU/Linux HWCAP values. These should be synced with kernel > > + definitions. */ > > +#define HWCAP_APIA (1 << 16) > > +#endif > > Re. the #ifndef, consider that tdep.h files are included in cross > debugger builds. E.g., an x86-hosted gdb cross debugging aarch64. > Some archs have "namespaced" names like the s390 mips, sparc, etc. > (e.g., HWCAP_S390_VX) which avoids the case of the names being defined > on host/target with a different meanings/values, but not all do. > But even with such names, we always have to provide fallback definitions > for cross debuggers. And with that all in mind, and since you're defining > fallbacks anyway, how about unconditionally defining/using our > own conflict-resistant versions, like AARCH64_HWCAP_APIA? > I am inclined to use the same macro name as kernel uses. These macros are only used in $arch-linux-{tdep,nat}.c, so it is clear that the macros are about architecture $arch. -- Yao (齐尧)