From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52802 invoked by alias); 13 Aug 2019 13:50:01 -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 52781 invoked by uid 89); 13 Aug 2019 13:50:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.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; Tue, 13 Aug 2019 13:49:59 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7DDlxXQ154840 for ; Tue, 13 Aug 2019 09:49:57 -0400 Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0b-001b2d01.pphosted.com with ESMTP id 2ubvn5w3n1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Aug 2019 09:49:52 -0400 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x7DDix69012082 for ; Tue, 13 Aug 2019 13:49:38 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma03wdc.us.ibm.com with ESMTP id 2u9nj62rhc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Aug 2019 13:49:38 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x7DDna7i52494722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Aug 2019 13:49:36 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 98DD3AC05F; Tue, 13 Aug 2019 13:49:36 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6C64FAC060; Tue, 13 Aug 2019 13:49:36 +0000 (GMT) Received: from pedro.localdomain (unknown [9.18.235.79]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 13 Aug 2019 13:49:36 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id 996923C0420; Tue, 13 Aug 2019 10:49:33 -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: <20190809152845.C680AD802D2@oc3748833570.ibm.com> Date: Tue, 13 Aug 2019 13:50:00 -0000 Message-ID: <87ftm56uqg.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-08/txt/msg00265.txt.bz2 "Ulrich Weigand" writes: >> 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). I inspected the kernel code in more detail, and some configurations can result in a non-contiguous range of slots after all. For instance, some embedded processor configurations with only two (instead of four) hardware breakpoints will return slots 1 and 2 for these, and 5 and 6 for the hardware watchpoints. Trying to delete slots 3 and 4 would always return EINVAL. To avoid tracking slots, we could try to delete slots in sequence, while counting the number of successful deletions and ENOENT errors, and ignoring EINVAL errors. Once this count is equal to num_instruction_bps + num_data_bps, this should mean that we cleared all the debug registers. I don't think this is the way the interface was intended to be used (see linux/Documentation/powerpc/ptrace.txt), since the slots sometimes represent an event with more than one debug register, but it does simplify how we handle this in GDB. Note that we'll still have to keep track of which slots that were installed by GDB are hardware breakpoints, and not watchpoints, to differentiate them when we get a trap (this is done in stopped_data_address). Is this an acceptable solution, or should we keep track of installed slots across clones and forks? Should there be some limit to how many EINVALs we see before we give up deleting the slots? Thanks! -- Pedro Franco de Carvalho