From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65442 invoked by alias); 19 Jun 2016 18:29:16 -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 65426 invoked by uid 89); 19 Jun 2016 18:29:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=watching, watched, 0xff000000, Hx-languages-length:2424 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; Sun, 19 Jun 2016 18:29:14 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 4E539461C7; Sun, 19 Jun 2016 18:29:13 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5JIT9Wm001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Jun 2016 14:29:12 -0400 Date: Sun, 19 Jun 2016 18:29: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: <20160619182909.GA9883@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <380b5288-f46f-3e20-c9c3-8cc8738ee322@redhat.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00315.txt.bz2 On Wed, 08 Jun 2016 20:46:35 +0200, Pedro Alves wrote: > 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. 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' main () at :3 3 in $1 = 0 '\000' $2 = 255 '\377' But you are right the watchpoint gets missed if the program writes to &global.buf[0] a 4-byte value not modifying the contents of global.buf[1] but modifying the contents of global.buf[3]: echo -e 'union { char buf[8]; unsigned long ul; } u; int main(void) {\n u.ul=0xff000000;\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 'b 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] Breakpoint 4 at 0x400570: file , line 3. Continuing. Breakpoint 4, main () at :3 3 in $1 = 0 '\000' $2 = 255 '\377' I will follow with an add-on patch as I guess you think it makes sense to fix GDB even for older kernels (assuming aarch64 kernel gets fixed in some time). Thanks, Jan