Re: Hardware watchpoints

[Eli Zaretskii <eliz at gnu dot org>]

> > > Evaluating the expression foo.x, I think, produces two values: one for
> > > 'foo', which is lazy, and a second for the '.x' member of the first
> > > value, which is no longer lazy.
> > 
> > The question is: what happens for foo->x.  Since foo can changein this
> > case, GDB has to watch both foo and foo->x.  But it does NOT have to
> > watch *foo.
> 
> Evaluating foo->x, I believe the values on the chain would be foo (not
> lazy), and foo->x (not lazy).  So that would work correctly.
> 
> Even evaluating (*foo).x, I believe you'd get foo (not lazy), *foo
> (lazy), and (*foo).x (not lazy).  So that would work too.
> 
> 
> >Could you suggest a quick hack to test whether this works?  If so, I
> >could try to see if that solvces the problem (and whether it introduces
> >new ones ;-).
> 
> Here's an untested patch:

Unfortunately, this doesn't work.  The effect of this change is that
hardware watchpoints aren't inserted at all.

I've poked around a little, and it seems that the lazy flag is set on
all members of the struct, not only on the struct itself.  It could be
that the reason is because value_primitive_field says something like
this (in more than one place):

      if (VALUE_LAZY (arg1))
	VALUE_LAZY (v) = 1;

I admit that I don't have enough insight into how the lazy flag is
used in GDB to suggest a solution.  But if you have further ideas for
testing, I will try them.

Thanks.