From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44020 invoked by alias); 9 Aug 2019 15:04:12 -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 44011 invoked by uid 89); 9 Aug 2019 15:04:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Aug 2019 15:04:10 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x79EmuMM018808 for ; Fri, 9 Aug 2019 11:04:08 -0400 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0b-001b2d01.pphosted.com with ESMTP id 2u9arasacy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 09 Aug 2019 11:04:08 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x79EpFHh006954 for ; Fri, 9 Aug 2019 15:04:07 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma04wdc.us.ibm.com with ESMTP id 2u51w6duh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 09 Aug 2019 15:04:07 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x79F46IW26607924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Aug 2019 15:04:06 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0F1D2112061; Fri, 9 Aug 2019 15:04:06 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D5A0F112063; Fri, 9 Aug 2019 15:04:05 +0000 (GMT) Received: from pedro.localdomain (unknown [9.80.195.227]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 9 Aug 2019 15:04:05 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id DAB243C03F3; Fri, 9 Aug 2019 12:04:02 -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: <20190809110434.C48D2D80277@oc3748833570.ibm.com> References: <20190809110434.C48D2D80277@oc3748833570.ibm.com> Date: Fri, 09 Aug 2019 15:04:00 -0000 Message-ID: <87y302753y.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-08/txt/msg00227.txt.bz2 "Ulrich Weigand" writes: > I may still be missing something, but why exactly *do* we need to know > which slots might already be installed? I'd have assumed that when we > get to low_prepare_to_resume, and the lwp is marked stale, we just throw > away everything and install the complete desired state. To throw away everything in low_prepare_to_resume, we need to know which slots the kernel had assigned to the debug registers we requested, because PPC_PTRACE_DELHWDEBUG takes the slot as an argument. Ideally we'd have a ptrace call to clear all the debug register state. I considered assuming that the kernel will always use a contiguous range of slots from 1 to num_instruction_bps + num_data_bps, and always deleting all these slots while ignoring ENODATA errors, but I'm not sure if this is a very robust solution. For instance, I inspected the kernel code, and in embedded processors, if you set a ranged breakpoint, this will occupy slots 1 and 2, and PPC_PTRACE_SETHWDEBUG will return slot 1. You then have to use slot 1 as an argument to PPC_PTRACE_DELHWDEBUG to delete the ranged breakpoint. If you try to delete slot 2 before 1, you'll get an EINVAL, and not an ENOENT. If you delete 1 then 2, you'll get ENOENT for 2. I fact, this case means that the solution I proposed in my previous reply of gathering all the slots from all threads in the same thread group would not work well (we could get EINVALs). >> Another reason is that add_lwp (and therefore low_new_thread) is also >> called in cases other than a ptrace clone event. > > Well, yes, but those cases *also* need to be handled, right? This is > e.g. when you attach to an already multi-threaded process while there > are already watchpoints set up. In that case, you'll need to install > those watchpoints into all those threads. This should already work, since we do set the stale flag in low_new_thread, like in other targets. We just don't copy any debug register state from other threads. So when we next resume the newly attached threads, we'll install the watchpoints GDB requested. However, I don't think that it's possible to handle cases where a previous tracer installed hardware breakpoints and watchpoints and then detached without removing them. Thanks! -- Pedro Franco de Carvalho