From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78084 invoked by alias); 28 Oct 2017 00:20:04 -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 78075 invoked by uid 89); 28 Oct 2017 00:20:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=verifications, iow, ctrl, H*u:6.1 X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 28 Oct 2017 00:20:02 +0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9S0JxbR019630 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Oct 2017 00:19:59 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v9S0JwuD019857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Oct 2017 00:19:58 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v9S0Jwt5011372; Sat, 28 Oct 2017 00:19:58 GMT Received: from [10.132.97.56] (/10.132.97.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Oct 2017 17:19:58 -0700 Subject: Re: [PING][PATCH PR gdb/21870] aarch64: Leftover uncleared debug registers To: Yao Qi Cc: "gdb-patches@sourceware.org" References: <1507328314-114545-1-git-send-email-weimin.pan@oracle.com> <300a7ff5-11c4-ef89-907a-c82c08973f29@oracle.com> <86she53qqc.fsf@gmail.com> From: Weimin Pan Message-ID: <284b4dcd-ed0d-73be-b506-01b67bb9262a@oracle.com> Date: Sat, 28 Oct 2017 00:20:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <86she53qqc.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-10/txt/msg00857.txt.bz2 On 10/27/2017 2:05 AM, Yao Qi wrote: > Wei-min Pan writes: > >> The most likely explanation is that ptrace() (1) does not validate contents >> in either address or control register, and (2) uses some default >> control values >> when setting hardware breakpoints. (2) is the main reason that contents in >> control register becomes non-zero after the aarch64_linux_set_debug_regs() >> call. BTW the value of 0x1fc in control register is not random but can be >> decoded as: >> >> "a watchpoint which is disabled, priv 2, 8-bytes, and of type hw_access" > The test case we got from Jan (in PR 21870) is that parent forks a > child, and read hw debug registers. The parent asserts on some bits of > debug registers read from child process. They are zero when the program > runs standalone, but they aren't zero after it runs within GDB. When it > runs in GDB, GDB is the grand-parent, in default, follow-fork-mode is > parent, and detach-on-fork is on, IOW, GDB (as a grandparent) only > attaches to the parent process, and leaves the child process run > freely. Then, the parent process reads some "unexpected" value from > child process, why is it a bug in the grandparent process? I believe that is because the grandparent process did modify the hardware registers in grandchild process, which was originated from aarch64_linux_new_thread() that set new thread's registers with DR_MARK_ALL_CHANGED().  It in turn caused aarch64_linux_set_debug_regs() to be called, regardless of whether or not these registers had really been changed, when the grandchild process was ready to resume execution. > Secondly, why is it valid to expect 'length' is zero when the debug > register is disabled? > > assert (DR_CONTROL_LENGTH (dreg_state.dbg_regs[0].ctrl) == 0); > > GDB thinks if debug register is disabled, then, it can be used. Now, > the observation is that when a debug register is disabled, the 'length' > can be different values in case that the process has tracer grandparent > or not. We may need to look into Linux kernel. > OK, but given that the ptrace() call made in aarch64_linux_set_debug_regs() to set debug registers didn't flag any error, it suggested that kernel didn't do any verifications on input parameters?