From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62949 invoked by alias); 10 Jun 2016 08:11:52 -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 62901 invoked by uid 89); 10 Jun 2016 08:11:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2182, watch X-HELO: mail-pf0-f173.google.com Received: from mail-pf0-f173.google.com (HELO mail-pf0-f173.google.com) (209.85.192.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Jun 2016 08:11:46 +0000 Received: by mail-pf0-f173.google.com with SMTP id c2so21481291pfa.2 for ; Fri, 10 Jun 2016 01:11:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=7OOLKqdApUmEzCzNRws2h9gUuilMhFOY2nJ3PqkahkM=; b=NvKMS2q5dCgEVnx9udbR4zczvD2tIVGXmLOjiAqKPfiwNLHmOO6aTGl1HClrUOk491 2X84af/cxzsQ2d8xcU82f+/LEb6iXrYwezfQkxMYOacjFZmPjc430HwWBwp0Ef/Sbs92 WbrOYaTWeJnOSCHEGvRMufW07yELcB+hpKpR/d4yKEpgYtcWNLQkm43Uh1LoDYWhTRlz cVXg/nFenzH8hIFhRKnbdJTYE1Q5frmnUkTLIjovLK1miyqm3oD230Y8ZI2NkQrvvAn4 G1664HCbek8fftbD7VrNmDHMxXTGnOuFDKW1zdmQAbhLlzRfzh5+nzrsswdBRM2ZuqxX 7QAQ== X-Gm-Message-State: ALyK8tIzG2xJdNt3nhKvSc1VtGTLoCYmLAz5R0+NsZ2ybvl7CC6KnlMDXywHiw4j5HSsVw== X-Received: by 10.98.27.216 with SMTP id b207mr929696pfb.111.1465546305003; Fri, 10 Jun 2016 01:11:45 -0700 (PDT) Received: from E107787-LIN (gcc113.osuosl.org. [140.211.9.71]) by smtp.gmail.com with ESMTPSA id k9sm15444160pao.19.2016.06.10.01.11.41 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 10 Jun 2016 01:11:44 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives References: <20160606075945.GA19395@host1.jankratochvil.net> <86eg89w2sr.fsf@gmail.com> <48622de4-dc45-c48f-7172-495b669f2334@redhat.com> <86a8ixvx5k.fsf@gmail.com> <7fabd183-eb46-e916-77f2-f62d5c4e4ce7@redhat.com> <86oa7bvdi0.fsf@gmail.com> <4f4d2f70-3931-6467-37c7-f97f99ad5c63@redhat.com> <380b5288-f46f-3e20-c9c3-8cc8738ee322@redhat.com> Date: Fri, 10 Jun 2016 08:11:00 -0000 In-Reply-To: <380b5288-f46f-3e20-c9c3-8cc8738ee322@redhat.com> (Pedro Alves's message of "Wed, 8 Jun 2016 19:46:35 +0100") Message-ID: <86k2hxv4xx.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: 2016-06/txt/msg00190.txt.bz2 Pedro Alves writes: > So I'm now thinking that the best is to extend the RSP somehow. > I think it is a good idea to extend the RSP... > I think that my preference is for the target to report a > memory range instead of a single address in the watchpoint=20 > stop reply. Like, e.g., if an access to address 10000006 triggers, > but all the target knows is that some address between 10000004 > and 10000008 was accessed, it reports: > > T05 watch:10000004-10000008 > > instead of: > > T05 watch:10000006 > > ( or maybe T05 watch:10000004;watch-end:10000008 ) > > This should be easy to implement in the target side, and > is practically stateless (a stub that just forwards requests > to a lower level debug api doesn't have to remember > the addresses gdb requested). > Right. > Then the corresponding target methods in gdb would work with an > address range instead of a single address too. E.g., > target_watchpoint_addr_within_range would be replaced by > a range overlap check. > > If the target knows the process stopped for a watchpoint, but > doesn't know the address that triggered, then it could report > the whole address space as range: > > T05 watch:00000000-ffffffff > > Note that it's not possible currently for a remote stub to tell gdb > that it doesn't know the address that trapped, even though the > target_ops:target_stopped_data_address method supports > returning false, and some native targets do make use of it. > > Alternatively, since we're extending the packet anyway, we > can make the address optional, thus making these equivalent: > > T05 watch:00000000-ffffffff > T05 watch: I prefer the latter, T05 watch:. > Alternatively, I though we could add a new qSupported feature value > that informs gdb of what is the watchpoint alignment and size > restriction, but I'm not so keen on that since the alignment > restriction may depend on mode (e.g., 32-bit vs 64-bit inferior), > or on the size of the area being watched, or some more complicated rule. Yes, there are different watchpoint alignment restrictions on arm and aarch64. --=20 Yao (=E9=BD=90=E5=B0=A7)