From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60299 invoked by alias); 8 Jun 2016 18:46:41 -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 60285 invoked by uid 89); 8 Jun 2016 18:46:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=keen, forwards, trapped, watch X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Jun 2016 18:46:38 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6910371095; Wed, 8 Jun 2016 18:46:37 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u58IkZSV017098; Wed, 8 Jun 2016 14:46:36 -0400 Subject: Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives To: Yao Qi 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> Cc: Jan Kratochvil , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <380b5288-f46f-3e20-c9c3-8cc8738ee322@redhat.com> Date: Wed, 08 Jun 2016 18:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <4f4d2f70-3931-6467-37c7-f97f99ad5c63@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00163.txt.bz2 On 06/08/2016 06:54 PM, Pedro Alves wrote: > How is this better than making it the responsibility of the > stub to report a stop data address that is within the address > range that gdb requested to watch, in the first place? I thought of a case where this is the wrong thing to do. (Alternative below.) The same example as before: e.g., a machine that only supports watching 32-bit-aligned words. Then with: union { char buf[4]; uint32_t force_align; } global; (gdb) watch global.buf[1]; Hardware watchpoint 1 ... (gdb) watch global.buf[3]; Hardware watchpoint 2 ... ... if the program writes to global.buf[3], and the target reports a memory access to 'global.buf + 1' (because that's the first watchpoint in its own watchpoint list that overlaps the global.buf[0]..global.buf[3] range (what is really being watched)), gdb will believe that watchpoint 1 triggered, notice the value didn't change, and thus incorrectly ignore the watchpoint hit. So I'm now thinking that the best is to extend the RSP somehow. I think that my preference is for the target to report a memory range instead of a single address in the watchpoint 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). 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: 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. Thanks, Pedro Alves