From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85339 invoked by alias); 20 Dec 2017 09:57:11 -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 85329 invoked by uid 89); 20 Dec 2017 09:57:10 -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=H*r:sk:clients, H*r:sk:static. X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Dec 2017 09:57:09 +0000 Received: by mail-wm0-f51.google.com with SMTP id 64so8541740wme.3 for ; Wed, 20 Dec 2017 01:57:09 -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=kJMtvVJmEgiVarhbDVfRrXJZNX8lTuhk3Xko69V709s=; b=RTT6Bb5j/XNILO6SZW+6Axe4T4QEB+Pdptk8VgUmHnPcXLLfsLFRSBHj3O9SCz0hqL Y/uZMEqPCFIeXEtnRhpq6wmh4JdHPQsQ9eVtZGl9zitaANOMWQyqapVNFhoqEegg7plp HQqhbT3Tmjc5Y2o0wgGr7/JifYylhcguN+eXDHa3FbAzdVwed5dTDTXaIJuw5gMdrBXq kB7zkMCTTJcTPFJOmEvqHLCj6Cw7wOQntgar9fd8aEAwWvuZh0V2yks1+Tf3jvHO6RO1 QDFhnTwZom56Oaq3CUvXG4DgYn+MHOt9B5S6P/Hu0w9Niw3nkJ1W8iUNYUhVJtojG1R1 lTaw== X-Gm-Message-State: AKGB3mLRymeJNjJMY36IYaLHhHCb0Tdb2sCaEPFV0u+ppkZMFs4d/BFm 8ucxmGdptgF4w7Rz20XdiWWuFQ== X-Google-Smtp-Source: ACJfBos4RG48ePgzRs1wgYMbs3qO3GKH4VuNkBkVLklglDxCSyciwJGNn+8/OlrHE/tw6Fb3OPFg5A== X-Received: by 10.28.24.210 with SMTP id 201mr6345919wmy.120.1513763827232; Wed, 20 Dec 2017 01:57:07 -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 y42sm13064939wrc.96.2017.12.20.01.57.06 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 20 Dec 2017 01:57:06 -0800 (PST) From: Yao Qi To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (GDB Patches) Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access References: <20171219161526.58C31D85C63@oc3748833570.ibm.com> Date: Wed, 20 Dec 2017 09:57:00 -0000 In-Reply-To: <20171219161526.58C31D85C63@oc3748833570.ibm.com> (Ulrich Weigand's message of "Tue, 19 Dec 2017 17:15:26 +0100 (CET)") Message-ID: <868tdxlo28.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/msg00441.txt.bz2 "Ulrich Weigand" writes: >> I am stilling thinking how to do it... alternatively, do you like the a= ppr=3D >> oach >> that we pass 'address' to gdbarch significant_addr_bits, and teach >> ppc32 gdbarch significant_addr_bits be aware of SPU address, that is, >> return 64 if the top bit is one (this address is the SPU address), >> otherwise, return 32 (this address is normal PPU address). > > Well, a simple workaround is to just always set significant_addr_bits > to 64 in ppc as well. (This just doesn't matter for actual ppc addresses= .) > But that doesn't really look like a clean solution for the generic > multi-architecture case ... Nowadays, we strip non-significant bits in address, pass the stripped address to target cache and to_xfer_partial. It works for aarch64, but breaks ppc32/spu. However, in ppc32/spu case, ppu address and spu address is mixed together, differentiated by the top bit, so the number of significant bits of address is 64, because if we can't remove any of them. IMO, it is reasonable to set significant_addr_bits to 64 in ppc. I considered your suggestion that pushing address_significant call down, below spu-multiarch target, that means, many target's to_xfer_partial need to call address_significant, so I don't do that. Secondly, in the way you suggested, we still pass the original address to target cache, which works for ppu/spu, but it doesn't work for aarch64. --=20 Yao (=E9=BD=90=E5=B0=A7)