From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31188 invoked by alias); 8 Aug 2019 20:27:42 -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 31177 invoked by uid 89); 8 Aug 2019 20:27:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:U*uweigand 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, 08 Aug 2019 20:27:40 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x78KMnPg056034 for ; Thu, 8 Aug 2019 16:27:38 -0400 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mx0a-001b2d01.pphosted.com with ESMTP id 2u8thvrjxs-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Aug 2019 16:27:38 -0400 Received: from localhost by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 Aug 2019 21:27:37 +0100 Received: from b03cxnp08027.gho.boulder.ibm.com (9.17.130.19) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 8 Aug 2019 21:27:36 +0100 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x78KRX7h43909430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Aug 2019 20:27:33 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C4C69C6055; Thu, 8 Aug 2019 20:27:33 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90257C605A; Thu, 8 Aug 2019 20:27:33 +0000 (GMT) Received: from pedro.localdomain (unknown [9.18.235.137]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 8 Aug 2019 20:27:33 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id 55A7A3C040A; Thu, 8 Aug 2019 17:27:29 -0300 (-03) From: Pedro Franco de Carvalho To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] [PowerPC] Fix debug register issues in ppc-linux-nat In-Reply-To: <20190808162423.C889CD802EF@oc3748833570.ibm.com> References: <20190808162423.C889CD802EF@oc3748833570.ibm.com> Date: Thu, 08 Aug 2019 20:27:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 19080820-0036-0000-0000-00000AE37670 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00011571; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000287; SDB=6.01243993; UDB=6.00656278; IPR=6.01025472; MB=3.00028097; MTD=3.00000008; XFM=3.00000015; UTC=2019-08-08 20:27:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19080820-0037-0000-0000-00004CF0A1EC Message-Id: <875zn7iery.fsf@linux.ibm.com> X-SW-Source: 2019-08/txt/msg00212.txt.bz2 "Ulrich Weigand" writes: > This looks generally good to me, just two questions: > > - As mentioned in the 1/3 patch, why do you need the low_new_clone > callback? As I understand it, you'll get low_new_thread called > immediatedly afterwards, which will mark the thread as "stale", > and once it is scheduled again, all debug regs will be set up > from scratch anyway ... The reason I did this is so that we have the lwp object of the parent thread, so that we can copy the correct debug register state. The arguments for low_new_thread don't include the parent. I think other targets always know how to clear all the debug registers without keeping track of anything, but we need to know which slots might already be installed in a new thread. Another reason is that add_lwp (and therefore low_new_thread) is also called in cases other than a ptrace clone event. One alternative solution is to use low_new_thread and iterate through all the known lwps in the same thread group, and copy state of installed slots (m_installed_hw_bps) from all threads to the state for the new thread. This should be sufficient for low_prepare_to_resume, since we just delete every slot ignoring ENOENT errors there. Wold something like this make sense? However, I'm not sure if this is robust enough to work even when add_lwp is used in other cases. > - We currently do not support hardware watchpoints in gdbserver, > even though we really should. Ideally, the low-level code to > handle debug regs should be shared between gdb and gdbserver, > as is done e.g. on x86. Now, I'm not saying that handling > gdbserver is a pre-req for this patch (fixing GDB first is of > course fine!), but I'm wondering if it would make sense, given > that you're refactoring a lot of this code anyway, to think > about whether this setup would help or hinder a future merge > with gdbserver. Ok, I'll review this and see if this can be easily ported to gdbserver. Thanks! -- Pedro Franco de Carvalho