From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12167 invoked by alias); 25 Aug 2010 23:02:20 -0000 Received: (qmail 12095 invoked by uid 48); 25 Aug 2010 23:02:20 -0000 Date: Wed, 25 Aug 2010 23:02:00 -0000 Message-ID: <20100825230220.12094.qmail@sourceware.org> From: "ppluzhnikov at google 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/msg00308.txt.bz2 ------- Additional Comments From ppluzhnikov at google dot com 2010-08-25 23:02 ------- (In reply to comment #5) > > 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. Confirmed: I don't. > "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? Yes, it's &ip: infrun: clear_proceed_status_thread (process 29122) infrun: proceed (addr=0xffffffffffffffff, signal=144, step=0) infrun: resume (step=0, signal=0), trap_expected=0 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = infrun: 29122 [process 29122], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400507 infrun: stopped by watchpoint infrun: stopped data address = 0x7fffffffd8d0 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_stepping Hardware access (read/write) watchpoint 1: *$1 Value = Hardware access (read/write) watchpoint 1: *$1 Value = main () at t.c:13 13 *ip = i; (gdb) p &i $2 = (int *) 0x7fffffffd8dc (gdb) p &ip $3 = (int **) 0x7fffffffd8d0 > 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? Good guess. But if I use 'watch *(int*)0x601010' instead of 'watch *$1', things get *much* worse, and GDB does start stepping: gcc -g t.c -DLIMIT=1 && /usr/bin/time gdb64-cvs -q -ex run -ex 'up 2' -ex 'print ip' -ex 'watch *(int*)0x90e3f0' -ex run -ex q ./a.out Reading symbols from /tmp/pr10557/a.out...done. Program received signal SIGABRT, Aborted. 0x00007ffff7ab0095 in raise () from /lib/libc.so.6 #2 0x000000000040051b in main () at t.c:15 15 abort(); $1 = (int *) 0x601010 Watchpoint 1: *(int*)0x601010 Program received signal SIGABRT, Aborted. 0x00007ffff7ab0095 in raise () from /lib/libc.so.6 5.83user 4.71system 0:10.68elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k Things to note above: 'Watchpoint 1' instead of 'Hardware watchpoint 1', and much slower execution even with just one iteration of the loop. Setting 'debug infrun' confirms that GDB is single-stepping in that case: infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x7ffff7df4b73 infrun: no stepping, continue infrun: resume (step=1, signal=0), trap_expected=0 infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 6262 [process 6262], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state ... When I do the watch manually, I can see the HW degrade into W (which is why I filed this bug in the first place): gdb64-cvs -q ./a.out Reading symbols from /tmp/pr10557/a.out...done. (gdb) r Program received signal SIGABRT, Aborted. 0x00007ffff7ab0095 in raise () from /lib/libc.so.6 (gdb) up 2 #2 0x000000000040051b in main () at t.c:15 15 abort(); (gdb) p ip $1 = (int *) 0x601010 (gdb) watch *(int*)0x601010 Hardware watchpoint 1: *(int*)0x601010 (gdb) r ... long delay here; note soft watchpoint below ... Watchpoint 1: *(int*)0x601010 Old value = New value = 0 0x00007ffff7b4e360 in brk () from /lib/libc.so.6 (gdb) q -- 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.