This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Hardware watchpoints


> I wonder, would it be possible to watch expressions like foo.x by
> having can_use_hardware_watchpoint ignore lval_memory values which are
> still lazy?  If a value is lazy, that means GDB never actually fetched
> it, but instead just used its address.

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 ;-).

As far as I remember from when I looked at this issue,
can_use_hardware_watchpoint is not the only place where it comes into
play: the other place is where GDB actually inserts the watchpoints.
What happens there is that GDB asks to watch a region the size of the
whole struct (or array, as the case may be), and any reasonable
implementation will refuse that, at least on x86.  (go32-nat.c has a
provision for watching up to 16-byte-long regions, but that's all.)

> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]