From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25430 invoked by alias); 7 Oct 2002 06:12:40 -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 25423 invoked from network); 7 Oct 2002 06:12:39 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 7 Oct 2002 06:12:39 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g976Cds07719 for ; Sun, 6 Oct 2002 23:12:39 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 6 Oct 2002 23:12:38 -0700 Received: from molly.local. (vpn-scv-x1-24.apple.com [17.219.193.24]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g976CcV26123; Sun, 6 Oct 2002 23:12:38 -0700 (PDT) Date: Sun, 06 Oct 2002 23:12:00 -0000 Subject: Re: [PATCH] Compare contents when evaluating an array watchpoint Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Eli Zaretskii From: Klee Dienes In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00169.txt.bz2 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). 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.