Message-ID: <4714FC32.4010707@portugalmail.pt>
Date: Tue, 16 Oct 2007 19:00:18 +0100
From: Pedro Alves <pedro_alves AT portugalmail DOT pt>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [gdb] Data watchpoints in Windows weirdness.  Call for testers.
References: <4702E6B7 DOT 8020100 AT portugalmail DOT pt> <20071008124331 DOT GD19254 AT calimero DOT vinschen DOT de> <20071008143552 DOT GA20746 AT ednor DOT casa DOT cgf DOT cx> <47115BEF DOT 7030407 AT portugalmail DOT pt> <ferqrc$ndc$1 AT ger DOT gmane DOT org> <47127845 DOT 5000905 AT portugalmail DOT pt> <20071015091947 DOT GS20400 AT calimero DOT vinschen DOT de> <4713B1FF DOT 4070709 AT portugalmail DOT pt> <ff1j4b$m5n$1 AT ger DOT gmane DOT org>
In-Reply-To: <ff1j4b$m5n$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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/