From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56678 invoked by alias); 16 Aug 2018 18:16:14 -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 54139 invoked by uid 89); 16 Aug 2018 18:15:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=target_ops 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, 16 Aug 2018 18:15:21 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7GIEItw128388 for ; Thu, 16 Aug 2018 14:15:18 -0400 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0a-001b2d01.pphosted.com with ESMTP id 2kwdddtk50-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Aug 2018 14:15:18 -0400 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 Aug 2018 14:15:17 -0400 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e13.ny.us.ibm.com (146.89.104.200) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 16 Aug 2018 14:15:14 -0400 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w7GIFDJH19464644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Aug 2018 18:15:13 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3281112069; Thu, 16 Aug 2018 14:14:51 -0400 (EDT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C056D112062; Thu, 16 Aug 2018 14:14:51 -0400 (EDT) Received: from pedro.localdomain (unknown [9.18.235.43]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 16 Aug 2018 14:14:51 -0400 (EDT) Received: by pedro.localdomain (Postfix, from userid 1000) id A41DE3C0452; Thu, 16 Aug 2018 15:15:10 -0300 (-03) From: Pedro Franco de Carvalho To: Pedro Alves , gdb-patches@sourceware.org Cc: uweigand@de.ibm.com, edjunior@gmail.com Subject: Re: [PATCH v4 10/12] [PowerPC] Add support for EBB and PMU registers In-Reply-To: <5c9f286a-8289-7984-c256-d19af8f797b5@redhat.com> References: <20180815000608.26840-1-pedromfc@linux.ibm.com> <20180815000608.26840-11-pedromfc@linux.ibm.com> <5c9f286a-8289-7984-c256-d19af8f797b5@redhat.com> Date: Thu, 16 Aug 2018 18:16:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 18081618-0064-0000-0000-0000033CD03C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009556; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000266; SDB=6.01074450; UDB=6.00553703; IPR=6.00854408; MB=3.00022760; MTD=3.00000008; XFM=3.00000015; UTC=2018-08-16 18:15:15 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18081618-0065-0000-0000-00003A53224E Message-Id: <87in4axjo1.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00409.txt.bz2 Pedro Alves writes: >> Since gdbserver writes all registers in one go before resuming the >> inferior, this error would not be detected at the time the user tries >> to write to one of the registers on the client side, and gdbserver >> would print out warnings every time it resumes the inferior when no >> ebb performance event is opened, so there is currently no >> straightforward way to handle this case. This means the ebb registers >> in the client-side regcache can become dirty when the user tries to >> write to them, until the inferior is resumed and stopped again. > > Should we make gdbserver flush the regcache after handling 'G' and 'P' > packets? Yes, I think this would work. It would have to flush the regcache and if anything goes wrong reply with an error packet. This would probably involve catching exceptions raised by target_ops::store_register in server.c. Thanks! -- Pedro Franco de Carvalho