Hardware watchpoints
Jim Blandy
jimb@cygnus.com
Wed Oct 20 09:35:00 GMT 1999
> > 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:
Index: breakpoint.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/breakpoint.c,v
retrieving revision 1.251
diff -c -c -b -F'^(' -r1.251 breakpoint.c
*** breakpoint.c 1999/09/30 03:29:33 1.251
--- breakpoint.c 1999/10/20 16:34:30
***************
*** 858,864 ****
for (; v; v = v->next)
{
/* If it's a memory location, then we must watch it. */
! if (v->lval == lval_memory)
{
CORE_ADDR addr;
int len, type;
--- 858,865 ----
for (; v; v = v->next)
{
/* If it's a memory location, then we must watch it. */
! if (v->lval == lval_memory
! && ! v->lazy)
{
CORE_ADDR addr;
int len, type;
***************
*** 5050,5056 ****
hardware watchpoint for the constant expression. */
for (; v; v = v->next)
{
! if (v->lval == lval_memory)
{
CORE_ADDR vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
int len = TYPE_LENGTH (VALUE_TYPE (v));
--- 5051,5058 ----
hardware watchpoint for the constant expression. */
for (; v; v = v->next)
{
! if (v->lval == lval_memory
! && ! v->lazy)
{
CORE_ADDR vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
int len = TYPE_LENGTH (VALUE_TYPE (v));
More information about the Gdb
mailing list