From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26649 invoked by alias); 20 Jun 2016 14:12:59 -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 26639 invoked by uid 89); 20 Jun 2016 14:12:59 -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=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; Mon, 20 Jun 2016 14:12:58 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 E5C398535A; Mon, 20 Jun 2016 14:12:56 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5KECrhu015597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 10:12:55 -0400 Date: Mon, 20 Jun 2016 14:12:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives Message-ID: <20160620141253.GA15735@host1.jankratochvil.net> 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> <20160619182909.GA9883@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00325.txt.bz2 On Mon, 20 Jun 2016 13:47:12 +0200, Pedro Alves wrote: > On 06/19/2016 07:29 PM, Jan Kratochvil wrote: > > On Wed, 08 Jun 2016 20:46:35 +0200, Pedro Alves wrote: > >> ... 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. > > > > Here if the program really does 'global.buf[3] = 0xff;' then it still does > > work as despite GDB places watchpoint at &global.buf[0] for 4 bytes aarch64 > > still reports the exact 1-byte location &global.buf[3]: > > echo -e 'union { char buf[8]; unsigned long ul; } u; int main(void) {\n u.buf[3]=0xff;\n return 0; }'|gcc -Wall -g -x c -;./gdb -data-directory ./data-directory/ ./a.out -ex start -ex 'watch u.buf[1]' -ex 'watch u.buf[3]' -ex c -ex 'p u.buf[1]' -ex 'p u.buf[3]' > > Hardware watchpoint 2: u.buf[1] > > Hardware watchpoint 3: u.buf[3] > > Continuing. > > Hardware watchpoint 3: u.buf[3] > > Old value = 0 '\000' > > New value = 255 '\377' > > Sounds what would happen when gdbserver looks for the first watchpoint > that overlaps the kernel-reported siginfo.si_addr trap address, it finds > watchpoint 3 first. What I was saying is that it is really not possible because for u.buf[3]=0xff; kernel does report siginfo.si_addr=0x4109bb And 'Hardware watchpoint 2' is only 2 bytes long (0x4109b8..0x4109b9 inclusive). > Which is entirely plausible because gdbserver actually iterates backwards: It really does not matter in which order the watchpoints are because only one watchpoint range (Hardware watchpoint 3) does match the reported address. Please verify the technical topics you are unsure about before correcting people. Thanks, Jan