From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44410 invoked by alias); 19 Dec 2017 16:15:38 -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 44292 invoked by uid 89); 19 Dec 2017 16:15:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Dec 2017 16:15:32 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJGExnK031501 for ; Tue, 19 Dec 2017 11:15:31 -0500 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ey3eyth5u-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Dec 2017 11:15:30 -0500 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Dec 2017 16:15:28 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 19 Dec 2017 16:15:27 -0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vBJGFQ0V54001780; Tue, 19 Dec 2017 16:15:26 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 21A5C4C058; Tue, 19 Dec 2017 16:10:05 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 10E6A4C046; Tue, 19 Dec 2017 16:10:05 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.213.29]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 19 Dec 2017 16:10:05 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 58C31D85C63; Tue, 19 Dec 2017 17:15:26 +0100 (CET) Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access To: qiyaoltc@gmail.com (Yao Qi) Date: Tue, 19 Dec 2017 16:15:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (GDB Patches) In-Reply-To: from "Yao Qi" at Dec 19, 2017 03:41:52 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17121916-0040-0000-0000-0000041BD450 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17121916-0041-0000-0000-000020BEF8D7 Message-Id: <20171219161526.58C31D85C63@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-19_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712190231 X-SW-Source: 2017-12/txt/msg00429.txt.bz2 Yao Qi wrote: > On Tue, Dec 19, 2017 at 1:50 PM, Ulrich Weigand wrote: > > 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. It's a "merged" address space containing the PowerPC address space (with top bit 0) as well as all the SPU address spaces (top bit 1, next 31 bits the SPU ID, last 32 bit the address on that SPU). I wouldn't need any of that if we actually supported "real" address spaces, i.e. instead of always passing just a CORE_ADDR, use a pair of address-space identifier and CORE_ADDR. But that would be a huge change, and so I worked around that by using the "merged" encoding. > > 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. Yes, that should still work (e.g. when the program stops anywhere, GDB will check software watchpoints that may be simultaneously set in SPU and PPU memory). Therefore target_thread_architecture doesn't really solve the problem either. > > 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). 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com