From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42840 invoked by alias); 8 Dec 2017 15:36:15 -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 42831 invoked by uid 89); 8 Dec 2017 15:36:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:D*de.ibm.com, H*r:sk:static. X-HELO: mail-wr0-f182.google.com Received: from mail-wr0-f182.google.com (HELO mail-wr0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Dec 2017 15:36:13 +0000 Received: by mail-wr0-f182.google.com with SMTP id s66so11185356wrc.9 for ; Fri, 08 Dec 2017 07:36:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6mxoTaZLCts8p6nXnW28gXPkM08/bqvadakiHzT8J7Q=; b=e1LPxCgUHPmJ4hewxW9xradkhdyIgE9HXcqMVpIsMw6D7tVusghbv+hS/SQg24S6+5 AhW+oPSXb3IPuBfQPKEbJLijX3nYqKD7sQRJjBiPLHnKpGSdl+eqScC5P68gkwz5xdCI 8L5kUjZhfPHaKzwt617n3C1YxV6MVGsKLiKlBAwyzly8PbKxp1XekwlGUn/p3G810Ig7 I7J+nhawT3O8ogSOTZ3ZI4crkqNjh25DgXBZkqxr+ibX4dKoBAWVE22kQFbf6cNSH98I YTnoDcuu/opy34NsexOiyXPAgSFJJI2ZKTlXAE9h2goun5Wf6nPdrcjb7U+BZFW1Ffiz 0Ejg== X-Gm-Message-State: AJaThX5DTC6q1YtAR8vTVNtD1QT957tzMjtgZgbk2zsmddiUUvqQY2jX ORFEimRgJ8GGEDsAOaDJ7dECbg== X-Google-Smtp-Source: AGs4zMY5laXoqJxCQZ1ofAt47SvckXs9wsE4Q+oogd+JQ+56gpkue5F6uAQDuI0mbzvoUnVAAVsHVA== X-Received: by 10.223.129.135 with SMTP id 7mr25308905wra.55.1512747371230; Fri, 08 Dec 2017 07:36:11 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id j125sm2097255wmd.24.2017.12.08.07.36.09 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 08 Dec 2017 07:36:10 -0800 (PST) From: Yao Qi To: "Ulrich Weigand" Cc: palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access References: <20171208151322.30013D8048A@oc3748833570.ibm.com> Date: Fri, 08 Dec 2017 15:36:00 -0000 In-Reply-To: <20171208151322.30013D8048A@oc3748833570.ibm.com> (Ulrich Weigand's message of "Fri, 8 Dec 2017 16:13:22 +0100 (CET)") Message-ID: <86374lp6zd.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00188.txt.bz2 "Ulrich Weigand" writes: > This seems to duplicate the functionality of gdbarch_addr_bits_remove > to some extent ... Could those be merged back again? They are a little bit different, addr_bits_remove only applies to PC (for arm and mips), but significant_addr_bit applies to every address (both data and instruction). On the other hand, the LSB of address in arm and mips is still significant, but it has some different meaning other than address when it is the target address of branch. We only clear the LSB when it is the target address. In normal memory access, watchpoing setting, we don't clear it. Simon asked the same question, see https://sourceware.org/ml/gdb-patches/2017-11/msg00213.html These two gdbarch methods are quite similar, but difficult to merge these two, unless we bring more context in the gdbarch hook method. --=20 Yao (=E9=BD=90=E5=B0=A7)