From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30337 invoked by alias); 29 Dec 2009 18:59:33 -0000 Received: (qmail 30329 invoked by uid 22791); 29 Dec 2009 18:59:32 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from e24smtp02.br.ibm.com (HELO e24smtp02.br.ibm.com) (32.104.18.86) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Dec 2009 18:59:28 +0000 Received: from mailhub3.br.ibm.com (mailhub3.br.ibm.com [9.18.232.110]) by e24smtp02.br.ibm.com (8.14.3/8.13.1) with ESMTP id nBTJ3Q83015826 for ; Tue, 29 Dec 2009 17:03:26 -0200 Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBTJ1Mt52302132 for ; Tue, 29 Dec 2009 17:01:22 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBTIxOUI011108 for ; Tue, 29 Dec 2009 16:59:24 -0200 Received: from [9.8.5.3] ([9.8.5.3]) by d24av02.br.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBTIxNum011087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 16:59:24 -0200 Subject: Re: [PATCH 1/2] Support the new PPC476 processor -- Arch Independent From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Eli Zaretskii Cc: gdb-patches@sourceware.org, bauerman@br.ibm.com, tyrlik@us.ibm.com In-Reply-To: <1262112901.5852.25.camel@gargoyle> References: <200912161847.19433.sergiodj@linux.vnet.ibm.com> <83vdg45xkx.fsf@gnu.org> <1262112901.5852.25.camel@gargoyle> Content-Type: text/plain; charset="UTF-8" Date: Tue, 29 Dec 2009 18:59:00 -0000 Message-ID: <1262113162.5852.27.camel@gargoyle> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-12/txt/msg00416.txt.bz2 Hey, On Tue, 2009-12-29 at 16:55 -0200, Luis Machado wrote: > > > -/* Check watchpoint condition. */ > > > +/* Check watchpoint condition. We can't use value_equal because it coerces > > > + an array to a pointer, thus comparing just the address of the array instead > > > + of its contents. This is not what we want. */ > > > + > > > +static int > > > +value_equal_watchpoint (struct value *arg1, struct value *arg2) > > > +{ > > > + struct type *type1, *type2; > > > + > > > + type1 = check_typedef (value_type (arg1)); > > > + type2 = check_typedef (value_type (arg2)); > > > + > > > + return TYPE_CODE (type1) == TYPE_CODE (type2) > > > + && TYPE_LENGTH (type1) == TYPE_LENGTH (type2) > > > + && memcmp (value_contents (arg1), value_contents (arg2), > > > + TYPE_LENGTH (type1)) == 0; > > > +} > > > > > > static int > > > watchpoint_check (void *p) > > > @@ -3246,7 +3388,7 @@ watchpoint_check (void *p) > > > > > > fetch_watchpoint_value (b->exp, &new_val, NULL, NULL); > > > if ((b->val != NULL) != (new_val != NULL) > > > - || (b->val != NULL && !value_equal (b->val, new_val))) > > > + || (b->val != NULL && !value_equal_watchpoint (b->val, new_val))) > > > > Can you elaborate the need for this change? It seems to change the > > semantics of watchpoint_check, so I wonder why it is done. > > > > It's done so we can detect triggers due to a range watchpoint. Since we > don't have the data address that caused the trigger, we need to go > through the entire range of a range watchpoint in order to tell if > something has changed. That's why we have a specific function to check > that (value_equal_watchpoint (b->val, new_val)). Just ignore this bit since Thiago already dealt with this one in his recent patch. Luis