This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/10557] HW watchpoints silently degrade into SW ones
- From: "pedro at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: 25 Aug 2010 22:37:13 -0000
- Subject: [Bug breakpoints/10557] HW watchpoints silently degrade into SW ones
- References: <20090824231914.10557.ppluzhnikov@google.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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 = <unreadable>
> Hardware access (read/write) watchpoint 1: *$1
>
> Value = <unreadable>
> 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 (<unreadable>).
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.