Re: [PATCH] Compare contents when evaluating an array watchpoint

[Klee Dienes <klee at apple dot com>]

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.