From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34118 invoked by alias); 19 Dec 2017 15:41:57 -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 34102 invoked by uid 89); 19 Dec 2017 15:41:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2080, HTo:U*uweigand X-HELO: mail-qk0-f178.google.com Received: from mail-qk0-f178.google.com (HELO mail-qk0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Dec 2017 15:41:54 +0000 Received: by mail-qk0-f178.google.com with SMTP id q14so10230131qke.7 for ; Tue, 19 Dec 2017 07:41:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8wzXLlOTtOJWVT55xBNJNd4baOh5oLrQbje+gRXluz8=; b=W4V4pMHX9+74NtTnlGdr4NGSV1WEE2NIKeoqj4uYqDr4kRFmKCdnUoU9hXqScGNP3U C6rGYcgK7BYTtNdoPlX199h+Jy5sCJRiMofnX6n/QFOnO/KjcCLpCf8Eht3DKDDpQLQp i9qX5xHmKlNkhmNKNu3U6cGmmycWZlXUx60Lbj6HpIEdvwoaKqi99drbERRRc/dGjUH1 2BaZJQPwWPbxUjchbUyez6VDJEofCPSDubmyIfw3DmjO9aXTyfB6acuamj+W7gSLSehW AwtIov0ndheUyd5IX8MJKK3yfYxnfjKJYBNLQAnVqaSUDn9dBUHrQjwgR7bFR5ZCmfWH daKQ== X-Gm-Message-State: AKGB3mKBEVIUfZH/Lb1k5OGMQS8+d3/DTxEH5+2QmDRIksOSU7H6q490 Yxf3YhQHJPfu7KzTCELRpbntfg3+vbI992G8Les= X-Google-Smtp-Source: ACJfBotT9JgEXvGTny+xLNid8SpY7buT6yAnA+eNYLKzW3t2zncS0Z1wYm18wZFIjXFicvAwpM3tLntIo9IdN47wWTg= X-Received: by 10.55.105.5 with SMTP id e5mr5477460qkc.256.1513698113238; Tue, 19 Dec 2017 07:41:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.132.161 with HTTP; Tue, 19 Dec 2017 07:41:52 -0800 (PST) In-Reply-To: <20171219135048.A25D9D85C63@oc3748833570.ibm.com> References: <1512727471-30745-2-git-send-email-yao.qi@linaro.org> <20171219135048.A25D9D85C63@oc3748833570.ibm.com> From: Yao Qi Date: Tue, 19 Dec 2017 15:41:00 -0000 Message-ID: Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access To: Ulrich Weigand Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00427.txt.bz2 On Tue, Dec 19, 2017 at 1:50 PM, Ulrich Weigand wrote: > Yao Qi wrote: > >> diff --git a/gdb/target.c b/gdb/target.c >> index 3b8b8ea..767a2ad 100644 >> --- a/gdb/target.c >> +++ b/gdb/target.c >> @@ -1214,6 +1214,8 @@ memory_xfer_partial (struct target_ops *ops, enum = target_object object, >> if (len =3D=3D 0) >> return TARGET_XFER_EOF; >> >> + memaddr =3D address_significant (target_gdbarch (), memaddr); >> + >> /* Fill in READBUF with breakpoint shadows, or WRITEBUF with >> breakpoint insns, thus hiding out from higher layers whether >> there are software breakpoints inserted in the code stream. */ > > It turns out this breaks SPU multi-architecture debugging. The problem is > that SPU memory addresses have 64 significant bits since we encode the > SPU ID in the upper 32 bits. This means that spu-tdep.c needs to call > set_gdbarch_significant_addr_bits -- which is fine. > Right, or SPU memory address has 63 significant bits? The top bit is 1. > However, this doesn't fix the problem, since "target_gdbarch ()" at this > point may well return a (32-bit) ppc architecture, and then the address > is still truncated incorrectly. In general, using target_gdbarch is > nearly never the right thing to do in generic code as long as we want > to support multi-architecture debugging. > Can we use target_thread_architecture (inferior_ptid) instead? If GDB still access SPU memory even program stops in PPU, this doesn't work. > Can this call not be pushed down further in the target stack, to below I think you meant "Can this call be", without "not". > the xfer_partial implementation in the spu-multiarch target? > I am stilling thinking how to do it... alternatively, do you like the appr= 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). --=20 Yao (=E9=BD=90=E5=B0=A7)