From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94470 invoked by alias); 9 Aug 2019 15:28:54 -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 94462 invoked by uid 89); 9 Aug 2019 15:28:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 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 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, 09 Aug 2019 15:28:52 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x79FOhWP076997 for ; Fri, 9 Aug 2019 11:28:50 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 2u98d3gkxn-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 09 Aug 2019 11:28:50 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Aug 2019 16:28:48 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 9 Aug 2019 16:28:47 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x79FSkQk52101234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Aug 2019 15:28:46 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 275B44C044; Fri, 9 Aug 2019 15:28:46 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 203994C04E; Fri, 9 Aug 2019 15:28:46 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.214.225]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 9 Aug 2019 15:28:46 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id C680AD802D2; Fri, 9 Aug 2019 17:28:45 +0200 (CEST) Subject: Re: [PATCH 3/3] [PowerPC] Fix debug register issues in ppc-linux-nat To: pedromfc@linux.ibm.com (Pedro Franco de Carvalho) Date: Fri, 09 Aug 2019 15:28:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <87y302753y.fsf@linux.ibm.com> from "Pedro Franco de Carvalho" at Aug 09, 2019 12:04:01 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 19080915-0012-0000-0000-0000033CC3F9 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19080915-0013-0000-0000-00002176CA68 Message-Id: <20190809152845.C680AD802D2@oc3748833570.ibm.com> X-SW-Source: 2019-08/txt/msg00229.txt.bz2 Pedro Franco de Carvalho wrote: > "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. Huh. I wasn't aware we didn't have such a method, but it does appear you're correct here. Weird. > 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). But it seems what would work reliably is to delete slots from 1 to max, while ignoring ENOENT, right? In fact, you don't even need to know the max slot number, because you'll get EINVAL if and only if you're attempting to delete the first slot after max (assuming you do it in sequence). > >> 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. The above method ought to handle that as well, I think. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com