From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128925 invoked by alias); 10 Mar 2017 17:12:41 -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 128909 invoked by uid 89); 10 Mar 2017 17:12:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=ulrich, H*i:sk:402e87d, Weigand, weigand 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; Fri, 10 Mar 2017 17:12:39 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2AGxDhK101252 for ; Fri, 10 Mar 2017 12:12:38 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 2937knscen-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Mar 2017 12:12:38 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Mar 2017 17:12:34 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 10 Mar 2017 17:12:32 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v2AHCVpw20709558; Fri, 10 Mar 2017 17:12:31 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 15C5242041; Fri, 10 Mar 2017 17:12:19 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EAE834204B; Fri, 10 Mar 2017 17:12:18 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.164.174.223]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 10 Mar 2017 17:12:18 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id A9A22D806B1; Fri, 10 Mar 2017 18:12:30 +0100 (CET) Subject: Re: [PATCH 0/7] Pass ptid to target_ops register methods To: simon.marchi@ericsson.com (Simon Marchi) Date: Fri, 10 Mar 2017 17:12:00 -0000 From: "Ulrich Weigand" Cc: palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org In-Reply-To: <402e87d0-f05a-07dc-fb3f-0c0bbc5eef28@ericsson.com> from "Simon Marchi" at Mar 10, 2017 11:06:06 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17031017-0008-0000-0000-000003FC5CD7 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17031017-0009-0000-0000-00001CC56CC0 Message-Id: <20170310171230.A9A22D806B1@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-10_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703100135 X-SW-Source: 2017-03/txt/msg00136.txt.bz2 Simon Marchi wrote: > Huh, good point. At first I wasn't sure I liked it, because I thought > the method interfaces would clearer with the ptid as its own parameter. > However, it would probably be more error-prone, because it would make it > possible to call to_fetch/store_register with a regcache that doesn't > match the provided ptid. Actually, in the current state, I guess it's > also possible to call to_fetch/store_register with a regcache that > doesn't match inferior_ptid. It is possible, but that would be a bug :-) All callers currently do struct cleanup *old_chain = save_inferior_ptid (); inferior_ptid = regcache->ptid; target_fetch_registers (regcache, regnum); or the equivalent. > In that regard, using the ptid from the > regcache is probably the safest thing to do. I'll try that. Basically, we should move the above from the call site into all implementations of the routine, and then push it down as far as possible until it hopefully disappears in most cases. > Looking at the comments in regcache: > > /* Is this a read-only cache? A read-only cache is used for saving > the target's register state (e.g, across an inferior function > call or just before forcing a function return). A read-only > cache can only be updated via the methods regcache_dup() and > regcache_cpy(). The actual contents are determined by the > reggroup_save and reggroup_restore methods. */ > int readonly_p; > /* If this is a read-write cache, which thread's registers is > it connected to? */ > ptid_t ptid; > > I understand that in some situations, a regcache can have a minus_one ptid. > However, it looks like a regcache with an invalid ptid is never used to > directly fetch and store registers. Instead, it is used as a "backup", the > content being copied from and to a regcache connected to a thread. Does > that sound right? Yes, the target routines must only be called on a regcache that is associated with a ptid. You'll probably need to add a get_regcache_ptid() routine or so; that routine should assert that the regcache has a ptid. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com