From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3047 invoked by alias); 22 Oct 2002 00:44:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3040 invoked from network); 22 Oct 2002 00:44:29 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Oct 2002 00:44:29 -0000 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 7ADDA800084 for ; Mon, 21 Oct 2002 20:44:29 -0400 (EDT) Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9AF1A3E13; Mon, 21 Oct 2002 20:44:28 -0400 (EDT) Message-ID: <3DB49F6C.3060106@redhat.com> Date: Mon, 21 Oct 2002 17:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klee Dienes Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Compare contents when evaluating an array watchpoint References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00374.txt.bz2 [suggest RFA rather than PATCH] >> There's two phases to the process by which GDB handles watchpoints, a "trigger" phase, where GDB causes itself to be stopped in any circumstance where the watchpoint might have been changed (either by hardware registers, page-protections, or single-stepping), and a "compare" phase, where it checks the value of the data being watched to see if it has actually changed. My patch doesn't change the behavior of the trigger phase at all --- this phase has always set the trigger to watch the entire contents of the array. >> >> My patch changes only the "compare" phase, by causing it to actually compare the contents of the array. The one performance implication I can think of is that watching large arrays could be unpleasant on systems that can only do breakpoints via single-stepping (whereas before it would have been impossible, so I'm not overly concerned). (Like Eli, I'm puzzled by the existing behavior :-) Just to get this straight. given: int a[10]; then: (gdb) watch a sets up the hardware to look for a change in ``*a@10'' but then evaluates ``a'' and hence, while stopping when ever `a' changes, never trigger the watchpoint? Would it be better to make it possible for the user to clearly differentiate between these two cases and specify any of: int a[10]; int *b; (gdb) watch a (gdb) watch b (gdb) watch *b@10 (gdb) watch *a@sizeof(a) While the existing ``watch a'' might have annoying semantics, it would make its behavior consistent with C. An array is converted to a pointer in an expression. I'm not sure how well this would work with the expression evaluator though. What ever the outcome, this desperatly needs a testcase. Otherwize we're all going to keep spinning our weels wondering what the behavior was ment to be. Andrew > > On Monday, October 7, 2002, at 01:53 AM, Eli Zaretskii wrote: > > On Sun, 6 Oct 2002, Klee Dienes wrote: > >> The following patch allows one to set watchpoints on arrays, and have >> the watchpoint triggered if any element in the array changes. Without >> the patch, the C value_equal semantics causes the address of the array >> to be checked for change, not the contents --- resulting in a >> watchpoint that can never be hit. >> >> This is particularly useful if one wants to do commands like watch >> {char[80]} 0xfff0000, or similar, in order to watch an arbitrary region >> of memory. >> >> What will this do to hardware watchpoints on arrays/array elements? On >> many platforms, hardware watchpoints have size limitations, so large >> arrays cannot be watched in their entirety. >> >