From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87968 invoked by alias); 23 Oct 2017 16:38:07 -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 87952 invoked by uid 89); 23 Oct 2017 16:38:07 -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=Hx-languages-length:945 X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Oct 2017 16:38:06 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9NGc39D032516 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Oct 2017 16:38:03 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9NGc2rK028107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Oct 2017 16:38:03 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9NGc2ax019778; Mon, 23 Oct 2017 16:38:02 GMT Received: from [10.159.141.25] (/10.159.141.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Oct 2017 09:38:02 -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> From: Wei-min Pan Message-ID: Date: Mon, 23 Oct 2017 16:38: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00727.txt.bz2 Hi Yao, 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" Wei-min On 10/22/2017 2:15 PM, Yao Qi wrote: > On Sat, Oct 21, 2017 at 1:58 AM, Wei-min Pan wrote: > > Hi Wei-min, > As I asked in comment 3 in PR 21870, could you > help me to understand the bug? I don't see how > does GDB touches hw debug registers, in this case. I have no idea that > why DR_CONTROL_LENGTH (dreg_state.dbg_regs[0].ctrl) is changed to > non-zero. >