From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15967 invoked by alias); 4 Mar 2009 19:20:28 -0000 Received: (qmail 15958 invoked by uid 22791); 4 Mar 2009 19:20:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog107.obsmtp.com (HELO eu1sys200aog107.obsmtp.com) (207.126.144.123) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Mar 2009 19:20:18 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKSa7UbwyAk/r9wJxa94z4ovNMQ6v/F2/H@postini.com; Wed, 04 Mar 2009 19:20:17 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D2EC9DA4E for ; Wed, 4 Mar 2009 19:19:21 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7645E4C63C for ; Wed, 4 Mar 2009 19:20:14 +0000 (GMT) Received: from [164.129.14.85] (bri1017.bri.st.com [164.129.14.85]) by mail1.bri.st.com (MOS 3.8.7a) with ESMTP id CLJ16479 (AUTH antony); Wed, 4 Mar 2009 19:20:13 GMT Message-ID: <49AED46D.7010701@st.com> Date: Wed, 04 Mar 2009 19:20:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: [GDB 6.8] Problem using watchpoints with compound objects References: <49AD6B30.2010102@st.com> <20090303203309.GA2672@caradoc.them.org> <49AD9E8A.3020608@st.com> <20090303214606.GA9404@caradoc.them.org> In-Reply-To: <20090303214606.GA9404@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00038.txt.bz2 OK. I now understand why the "struct" example below was not working and my false assumption that coerce_array() was the culprit in both cases (I checked the array case but assumed it was the same for the struct :-( ). The reason why it was not working was because I was initially running the program with the following GDB script: file a.out break main run watch a continue Using the above script I see the following output from GDB (using the snapshot version 6.8.50.20090303): > Breakpoint 1 at 0x8048320: file a.c, line 4. > > Breakpoint 1, main () at a.c:4 > 4 a.m1 = 1; > Hardware watchpoint 2: a > > Program exited normally. which shows that the watchpoint is not being reported. However if I replace "break main" with "tbreak main" in the above script I see the watchpoint being reported, as follows: > Temporary breakpoint 1 at 0x8048320: file a.c, line 4. > > Temporary breakpoint 1, main () at a.c:4 > 4 a.m1 = 1; > Hardware watchpoint 2: a > Hardware watchpoint 2: a > > Old value = {m1 = 0, m2 = 0, m3 = 0, m4 = 0} > New value = {m1 = 1, m2 = 0, m3 = 0, m4 = 0} > main () at a.c:5 > 5 return 0; So in this instance it seems the problem has nothing to do with "a" being a struct object (as you correctly point out) but as a result of continuing from a breakpoint; a different GDB issue :-). However my original query relating to arrays is still valid. If I perform the same test with "a" defined as an array (as in my original email) then the effect of coerce_array() in value_equal() remains; the watchpoint is reported by the H/W but value_equal() will always report TRUE (since it compares the address of the array and not its contents) and hence GDB erroneously ignores the watchpoint as unchanged. Therefore I still think the change to watchpoint_check() is still valid. If you concur I will submit a patch for this. [Note that this was tested on RedHat EL3 and EL4 hosts with the same results.] Cheers, Antony. Daniel Jacobowitz wrote: > On Tue, Mar 03, 2009 at 09:18:02PM +0000, Antony KING wrote: >> struct {int m1, m2, m3, m4;} a; >> int main (void) >> { >> a.m1 = 1; >> return 0; >> } >> >> In both cases value_equal is comparing the address of the object and not >> the contents. This is caused, I believe, by the following code at the >> start of value_equal: >> >> arg1 = coerce_array (arg1); >> arg2 = coerce_array (arg2); >> >> which is converting the compound objects into pointers. These are then >> used in the latter tests of value_equal. > > Arrays are supposed to be handled specially, but I was talking about > structs since that was in your original example. coerce_array has no > effect on structs.