This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gdb] Data watchpoints in Windows weirdness. Call for testers.


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]