From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5558 invoked by alias); 3 Mar 2009 17:39:08 -0000 Received: (qmail 5549 invoked by uid 22791); 3 Mar 2009 17:39:07 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog105.obsmtp.com (HELO eu1sys200aog105.obsmtp.com) (207.126.144.119) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 17:39:01 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKSa1rMvvrBiXitdMLkJBifkY127yUKB9h@postini.com; Tue, 03 Mar 2009 17:39:01 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 5926DDA4B for ; Tue, 3 Mar 2009 17:38:06 +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 6C4C74C4AF for ; Tue, 3 Mar 2009 17:38:57 +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 CLJ04764 (AUTH antony); Tue, 3 Mar 2009 17:38:57 GMT Message-ID: <49AD6B30.2010102@st.com> Date: Tue, 03 Mar 2009 17:39:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: gdb@sourceware.org Subject: [GDB 6.8] Problem using watchpoints with compound objects Content-Type: multipart/mixed; boundary="------------060003090104040503090809" 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/msg00025.txt.bz2 This is a multi-part message in MIME format. --------------060003090104040503090809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 1898 I am investigating a problem with H/W watchpoints on compound objects in GDB 6.8 whereby they are not being set in the target nor are they being detected as being changed (once the first problem is fixed). Take for example the following simple application: int a[4]; int main (void) { a[0] = 1; return 0; } Problem 1 - watchpoint is not set --------------------------------- If I issue "watch a" to GDB then GDB reports that it has set a H/W watchpoint but when I continue the watchpoint is not being set. This I believe is due to a problem in update_watchpoints() in the following test: if (v == b->val || (TYPE_CODE (vtype) != TYPE_CODE_STRUCT && TYPE_CODE (vtype) != TYPE_CODE_ARRAY)) The if is unnecessary failing since the test "v == b->val" is not taking into account that b->val may *not* have been set to v earlier on in the same function. Looking the CVS head this code has been modified so that this problem is no longer present. Making a similar change to GDB 6.8 seems to fix the problem (see patch1.txt). Is this solution correct ? Problem 2 - watchpoint is not detected -------------------------------------- After applying the patch for problem 1 I then encountered a second problem where a watchpoint is being erroneously dismissed as being unchanged. I believe this problem is due to the following test in watchpoint_check(): if (!value_equal (b->val, new_val)) This test is only comparing the address of the object and not its contents. I think the test should be revised to the following: if (!value_equal (b->val, new_val) || !value_contents_equal (b->val, new_val)) assuming that the value_equal() test is still required (otherwise the value_equal test could be dropped). Looking at the code in the CVS head the same issue still seems present. Do you think the above is sufficient to fix the problem ? Cheers, Antony. --------------060003090104040503090809 Content-Type: text/plain; name="gdb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb.patch" Content-length: 1833 --- breakpoint.c@@/INSIGHT-6.8-ST-2.0 2008-09-11 12:00:00.000000000 +0100 +++ breakpoint.c 2009-03-03 14:20:50.232257000 +0000 @@ -898,7 +898,7 @@ update_watchpoint (struct breakpoint *b, is different from out-of-scope watchpoint. */ if (within_current_scope && b->exp) { - struct value *v, *next; + struct value *v, *result, *next; /* Evaluate the expression and make sure it's not lazy, so that after target stops again, we have a non-lazy previous value @@ -910,18 +910,18 @@ update_watchpoint (struct breakpoint *b, In addition, we look at all values which were created during evaluation, and set watchoints at addresses as needed. Those values are explicitly deleted here. */ - v = evaluate_expression (b->exp); + result = evaluate_expression (b->exp); /* Avoid setting b->val if it's already set. The meaning of b->val is 'the last value' user saw, and we should update it only if we reported that last value to user. As it happens, the code that reports it updates b->val directly. */ if (b->val == NULL) - b->val = v; - value_contents (v); + b->val = result; + value_contents (result); value_release_to_mark (mark); /* Look at each value on the value chain. */ - for (; v; v = next) + for (v = result; v; v = next) { /* If it's a memory location, and GDB actually needed its contents to evaluate the expression, then we @@ -934,7 +934,7 @@ update_watchpoint (struct breakpoint *b, /* We only watch structs and arrays if user asked for it explicitly, never if they just happen to appear in the middle of some value chain. */ - if (v == b->val + if (v == result || (TYPE_CODE (vtype) != TYPE_CODE_STRUCT && TYPE_CODE (vtype) != TYPE_CODE_ARRAY)) { --------------060003090104040503090809--