From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124718 invoked by alias); 15 Mar 2018 14:06:36 -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 124367 invoked by uid 89); 15 Mar 2018 14:06:36 -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=Hx-languages-length:1197, Significant 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; Thu, 15 Mar 2018 14:06:35 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2FE6Xu0067561 for ; Thu, 15 Mar 2018 10:06:33 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gqqjahfu7-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Thu, 15 Mar 2018 10:06:32 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Mar 2018 14:06:28 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Mar 2018 14:06:25 -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 w2FE6PrC1442268; Thu, 15 Mar 2018 14:06:25 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E62CD4C19E; Thu, 15 Mar 2018 13:59:38 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DCED94C19D; Thu, 15 Mar 2018 13:59:38 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.213.54]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 15 Mar 2018 13:59:38 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id DEEACD804A7; Thu, 15 Mar 2018 15:06:24 +0100 (CET) Subject: Re: [PATCH] gdbarch: Add pc_signed field and use it when adjusting BP addresses To: vlad.ivanov@lab-systems.ru (Vlad Ivanov) Date: Thu, 15 Mar 2018 14:06:00 -0000 From: "Ulrich Weigand" Cc: schwab@suse.de (schwab@suse.de), gdb-patches@sourceware.org (gdb-patches@sourceware.org) In-Reply-To: <604111521119420@web34o.yandex.ru> from "Vlad Ivanov" at Mar 15, 2018 04:10:20 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18031514-0020-0000-0000-000004053B15 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18031514-0021-0000-0000-000042994404 Message-Id: <20180315140624.DEEACD804A7@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-15_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=18 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-1803150158 X-SW-Source: 2018-03/txt/msg00300.txt.bz2 Vlad Ivanov wrote: > 15.03.2018, 15:59, "Ulrich Weigand" : > > If the address is already correct, why don't you simply set > > gdbarch_significant_addr_bit > > to 64 in the mips back-end instead of adding a new gdbarch routine? > > That would affect address printing. I don't see how it can affect address printing. gdbarch_significant_addr_bit is not involved in that at all. > Moreover, semantically it's > probably not a good practice because the code would imply that for > all kind of MIPS all 64 bits of address are significant, whereas > in reality it differs from target to target. Well, all 64 bits *are* significant in the relevant sense here. "Significant" here only means, the bit already has the correct value that it needs to have if you want to access the intended memory word via ptrace. The only reason to ever set gdbarch_significant_addr_bit to anything less than the host word size is if addresses contain some tags or other extraneous bits that actively need to be trimmed. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com