From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48885 invoked by alias); 27 Oct 2017 09:05:56 -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 48868 invoked by uid 89); 27 Oct 2017 09:05:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=iow, H*r:sk:static. X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Oct 2017 09:05:55 +0000 Received: by mail-wm0-f66.google.com with SMTP id z3so2288852wme.5 for ; Fri, 27 Oct 2017 02:05:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=JU4oRidCGqG/ikSdtOQCPYjXQWbAYV6WlN48XgRJDQo=; b=X91klvmm7TLQ/zYRg6SqDsiD5I20ZYe5a6EZLwZUYcSZhbXCUg0Bf9VrisvtP2gpox smoy88raArJMnMJZqnSJ08QhugjexZFc4++4axNZIuf60o9icAYgmfkksBqoiu96iAj4 wjxS15pAcVz49q5DEfzRjTu/8bZ4y1zfnXlpIYRNrREuYNiQAODwjfqwt1LLdGvA8ghp PtiBqxs6ciAVRw/3kjbALMxCdf10JUEwZgrchs5gKT1C60e6tScI9KFk2d9eWw/rt4CR 8m9kriF1noTS7wliGiQpPLDZcsPWv6Yhv+LNkGrmi0H6/ptpX9kJFA0PiiwUYBGKBJos 6KRw== X-Gm-Message-State: AMCzsaWn7LhnsqigBMAp/M5O9d9kHor9RccU09fWSMgGfH91fOiVlKqm ov/or7CxnqmYdSCpgrLrLjlGSw== X-Google-Smtp-Source: ABhQp+Skx6Wp8e2vOc+Zk2nq+P32T4CwuVkxop2yCKTsyf4vlgJyrLfFwNYWBIHsg5xSNcc1WjUQRA== X-Received: by 10.28.22.82 with SMTP id 79mr22408wmw.70.1509095152642; Fri, 27 Oct 2017 02:05:52 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id o135sm1283894wmg.1.2017.10.27.02.05.51 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 27 Oct 2017 02:05:52 -0700 (PDT) From: Yao Qi To: Wei-min Pan Cc: "gdb-patches\@sourceware.org" Subject: Re: [PING][PATCH PR gdb/21870] aarch64: Leftover uncleared debug registers References: <1507328314-114545-1-git-send-email-weimin.pan@oracle.com> <300a7ff5-11c4-ef89-907a-c82c08973f29@oracle.com> Date: Fri, 27 Oct 2017 09:05:00 -0000 In-Reply-To: (Wei-min Pan's message of "Mon, 23 Oct 2017 09:38:01 -0700") Message-ID: <86she53qqc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00837.txt.bz2 Wei-min Pan writes: > The most likely explanation is that ptrace() (1) does not validate conten= ts > 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? 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) =3D=3D 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. --=20 Yao (=E9=BD=90=E5=B0=A7)