From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19670 invoked by alias); 25 Aug 2010 22:37:13 -0000 Received: (qmail 19653 invoked by uid 48); 25 Aug 2010 22:37:13 -0000 Date: Wed, 25 Aug 2010 22:37:00 -0000 Message-ID: <20100825223713.19652.qmail@sourceware.org> From: "pedro at codesourcery dot com" To: gdb-prs@sourceware.org In-Reply-To: <20090824231914.10557.ppluzhnikov@google.com> References: <20090824231914.10557.ppluzhnikov@google.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug breakpoints/10557] HW watchpoints silently degrade into SW ones X-Bugzilla-Reason: CC Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00307.txt.bz2 ------- Additional Comments From pedro at codesourcery dot com 2010-08-25 22:37 ------- On Wednesday 25 August 2010 22:33:22, ppluzhnikov at google dot com wrote: > So the memory was inaccessible, and just became accessible, but hasn't been > written to in a loop. I believe this proves your theory incorrect. It actually does not. :-) See below. > It I set 'awatch', here is what I observe: Thanks. > gcc -g t.c -DLIMIT=100000 && /usr/bin/time gdb64-cvs -q -ex run -ex 'up 2' -ex > 'print ip' -ex 'awatch *$1' -ex 'run' ./a.out > Reading symbols from /tmp/pr10557/a.out...done. > > Program received signal SIGABRT, Aborted. > 0x00007ffff7ab0095 in raise () from /lib/libc.so.6 > #2 0x000000000040051e in main () at t.c:15 > 15 abort(); > $1 = (int *) 0x90e3f0 > Hardware access (read/write) watchpoint 1: *$1 > Hardware access (read/write) watchpoint 1: *$1 (...) > Value = > Hardware access (read/write) watchpoint 1: *$1 > > Value = > 0x0000000000400562 in __libc_csu_init () > > > Looks like something is single-stepping :-( I don't think it is. Go back to using "watch", reenable "set debug infrun 1", and confirm whether see a stream of things like these: > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc = 0x400507 > infrun: stopped by watchpoint > infrun: stopped data address = 0x7fffffffd9f0 > infrun: no stepping, continue > infrun: resume (step=0, signal=0), trap_expected=0 If you don't see "resume (step=1,...", then there's no single-stepping. "stopped by watchpoint" means that the target thinks the thread hit a watchpoint (because the debug registers claim so). But I now notice something: "0x7fffffffd9f0" is a suspicious address, and it does not look like 'i'. Is that a stack address? That might explain why does the access watchpoint cause a stop, only to then not be able to evaluate the expression (). I sounds like gdb thought it needed to set a watchpoint on &i to be able to watch your expression? -- http://sourceware.org/bugzilla/show_bug.cgi?id=10557 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.