From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68150 invoked by alias); 11 Feb 2019 19:10:29 -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 68139 invoked by uid 89); 11 Feb 2019 19:10:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=marks 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; Mon, 11 Feb 2019 19:10:28 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1BJ3ZQs116277 for ; Mon, 11 Feb 2019 14:10:27 -0500 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0a-001b2d01.pphosted.com with ESMTP id 2qkd45n21r-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 11 Feb 2019 14:10:26 -0500 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 11 Feb 2019 19:10:26 -0000 Received: from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 11 Feb 2019 19:10:23 -0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x1BJAMSL30736526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Feb 2019 19:10:22 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 58A807805E; Mon, 11 Feb 2019 19:10:22 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 083ED7805C; Mon, 11 Feb 2019 19:10:21 +0000 (GMT) Received: from pedro.localdomain (unknown [9.85.169.84]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 11 Feb 2019 19:10:21 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id 8C85A3C0552; Mon, 11 Feb 2019 17:10:18 -0200 (-02) From: Pedro Franco de Carvalho To: Simon Marchi , gdb-patches@sourceware.org Cc: uweigand@de.ibm.com, edjunior@gmail.com Subject: Re: [PATCH v5 12/12] [PowerPC] Add support for HTM registers In-Reply-To: References: <20181022223242.7858-1-pedromfc@linux.ibm.com> <20181022223242.7858-13-pedromfc@linux.ibm.com> Date: Mon, 11 Feb 2019 19:10:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 19021119-0012-0000-0000-000017094AC8 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010578; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000279; SDB=6.01159627; UDB=6.00605167; IPR=6.00940173; MB=3.00025529; MTD=3.00000008; XFM=3.00000015; UTC=2019-02-11 19:10:24 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19021119-0013-0000-0000-0000562BD337 Message-Id: <87tvhauoo5.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00125.txt.bz2 Hello Simon, > From what I understand from the comment above, the problem is that raw_write_part > does not return any feedback. That's right, in the live frame an exception is raised only if the target is called to try to write to the register, which doesn't happen in regcache::raw_write_part when the initial read doesn't return a valid status. This initial read does go to the target, but it doesn't raise an exception, it just marks the register as unavailable. > [...] Would it be fine to make raw_write_part return a value > (probably a bool) to say whether it succeeded, and replace the current > error handling code with a check of that return value? Something > like: > > bool success = regcache->raw_write_part (vr0 + reg_index, offset, > register_size (gdbarch, reg_nr), buffer); > if (!success) > error (_("Cannot write to the checkpointed EFP register, " > "the corresponding vector register is unavailable.")); > This should work, although I wonder if it makes sense to return a register_status like the private regcache::raw_write_part already does, instead of a bool. This should also work nicely if the write is done for a regular EFP pseudo-register (as opposed to checkpointed one). Before your patch series, only the checkpointed version could result in an unavailable read, but now I think this can also happen to the regular one for a frame in which the underlying register wasn't saved. In fact, couldn't this silent failure now also affect other arches that use raw_write_part too, when the register is unavailable in a frame? A possible solution might be to raise an exception directly from register_readwriter::write_part when the read returns something other than REG_VALID, although I'm not sure this would be correct in all cases. The only detail is that "checkpointed" should be removed from the error message, so it becomes something like: if (regcache->get_register_status (vr0 + reg_index) != REG_VALID) error (_("Cannot write to the EFP register, the corresponding " "vector register is unavailable.")); (I also added a space before the string continuation which was previously missing). Thanks! -- Pedro Franco de Carvalho