Mail Archives: cygwin/2007/10/16/14:02:05
René Berber wrote:
> Pedro Alves wrote:
>
>> Corinna Vinschen wrote:
>
> Gdb 6.6 (installed with Insight 6.6) doesn't seem to have the problem:
>
Unfortunatelly it does. :( If you are seing a different output, it
may be because you built the test app with different -O setting.
-O0 is better for watchpoint support, as at higher optimization
levels, the variables may be loaded in registers, and so you won't
see some writes.
> 8 {
> (gdb) c
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> main () at test.c:11
> 11 printf ("count %d\n", count);
> (gdb)
> Continuing.
Here gdb could't determine which watchpoint triggered, so it
didn't evaluate the watched expressions, and didn't show
the old/new values. It should have shown:
> Old value = 0
> New value = 999
due to the 'count = 999;'
> Hardware watchpoint 1: count
>
> Old value = 0
> New value = 1000
Here you should have seen:
> Old value = 999
> New value = 1000
The problem is shown in your log file:
> gdb: kernel event for pid=1444 tid=2104 code=EXCEPTION_DEBUG_EVENT)
> gdb: Target exception EXCEPTION_SINGLE_STEP at 0x00401099
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x401099
> stopped_data_addr:
> CONTROL (DR7): 000d0101 STATUS (DR6): 00000000
^^^^^^^^
DR6 should have been != 0.
> DR0: addr=0x00403010, ref.count=1 DR1: addr=0x00000000, ref.count=0
> DR2: addr=0x00000000, ref.count=0 DR3: addr=0x00000000, ref.count=0
> infrun: random signal 5
^^^^^^^^^^^^^^^
Hence, gdb assumed it was random.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> infrun: stop_stepping
> remove_watchpoint (addr=403010, len=4, type=data-write):
> CONTROL (DR7): 000d0100 STATUS (DR6): 00000000
> DR0: addr=0x00000000, ref.count=0 DR1: addr=0x00000000, ref.count=0
> DR2: addr=0x00000000, ref.count=0 DR3: addr=0x00000000, ref.count=0
> main () at test.c:11
> 11 printf ("count %d\n", count);
> (gdb) c
I've reproduced it in a MinGW gdb. So I'm now 100% sure it is not a
Cygwin problem.
I'm still thinking that it is a gdb bug, in the sense that there must be
something different with the debug registers handling that I didn't quite
understand yet. I'll try to build a small native win32 minimal debugger
that reproduces it, and if that doesn't make the problem obvious, post
a query in some Windows discussion group.
Thanks again!
Cheers,
Pedro Alves
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -