From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74535 invoked by alias); 9 Nov 2017 20:30: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 73968 invoked by uid 89); 9 Nov 2017 20:30:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=agent X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Nov 2017 20:30:45 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 342AFC056870; Thu, 9 Nov 2017 20:30:44 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8C18460F90; Thu, 9 Nov 2017 20:30:43 +0000 (UTC) Subject: Re: [PATCH 3/3] [AArch64] Remove tag from address for watchpoint To: Yao Qi , gdb-patches@sourceware.org References: <1509006590-9401-1-git-send-email-yao.qi@linaro.org> <1509006590-9401-4-git-send-email-yao.qi@linaro.org> From: Pedro Alves Message-ID: <2fe62186-f1db-cf5c-f0e2-c18e35089dd9@redhat.com> Date: Thu, 09 Nov 2017 20:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1509006590-9401-4-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00210.txt.bz2 On 10/26/2017 09:29 AM, Yao Qi wrote: > +typedef CORE_ADDR (gdbarch_addr_tag_remove_ftype) (struct gdbarch *gdbarch, CORE_ADDR addr); > +extern CORE_ADDR gdbarch_addr_tag_remove (struct gdbarch *gdbarch, CORE_ADDR addr); > +extern void set_gdbarch_addr_tag_remove (struct gdbarch *gdbarch, gdbarch_addr_tag_remove_ftype *addr_tag_remove); > + > /* FIXME/cagney/2001-01-18: This should be split in two. A target method that > indicates if the target needs software single step. An ISA method to > implement it. > diff --git a/gdb/gdbarch.sh b/gdb/gdbarch.sh > index 6459b12..1f673e7 100755 > --- a/gdb/gdbarch.sh > +++ b/gdb/gdbarch.sh > @@ -621,6 +621,11 @@ m;CORE_ADDR;convert_from_func_ptr_addr;CORE_ADDR addr, struct target_ops *targ;a > # possible it should be in TARGET_READ_PC instead). > m;CORE_ADDR;addr_bits_remove;CORE_ADDR addr;addr;;core_addr_identity;;0 > > +# On some machines, there are bits in address which are ignored by the > +# kernel, the hardeware, etc. They are called "tag", which can be > +# regarded as additional data associated with the address. > +m;CORE_ADDR;addr_tag_remove;CORE_ADDR addr;addr;;core_addr_identity;;0 typo: "hardeware". Hmmm. We have gdbarch_addr_bit / addr_bit to represent the size of a target address. I'm thinking that instead of addr_tag_remove, this would a bit more in line with the current scheme if this were a new "significant_addr_bit" gdbarch property? I.e.: /* On some machines, not all bits of an address word are significant. For example, on Aarch64, the top bits of an address known as the "tag" are ignored by the kernel, the hardware, etc. and can be regarded as additional data associated with the address. */ int gdbarch_significant_addr_bit (struct gdbarch *gdbarch); significant_addr_bit would default to addr_bit. And then at places where we need to save or compare memory addresses, like in the watchpoint location addresses case we strip out / ignore non-significant bits. And the next question is: if you're adding a gdbarch hook such as this one (either significant_addr_bit or addr_tag_remove) why not use it for all the cases handled by the different patches in this series, instead of using different solutions for each case? I.e., for memory access, saving breakpoint and watchpoint location addresses, the dcache, and any other future case we run into, like e.g., maybe agent expressions. Thanks, Pedro Alves