Re: Changing the "enclosing_type" of a value structure

[Eli Zaretskii <eliz at delorie dot com>]

> Date: Tue, 15 Aug 2000 16:08:36 -0700
> From: Jim Ingham <jingham@apple.com>
>
>     /* If zero, contents of this value are in the contents field.
>        If nonzero, contents are in inferior memory at address
>        in the location.address field plus the offset field
>        (and the lval field should be lval_memory).  */
>     char lazy;
>  
> This doesn't sound at first reading like the meaning that it is
> being given by the watchpoint code

You are right.  When use of the lazy flag was suggested for fixing the
problem with watchpoints (GDB was unable to watch struct members and
array elements, it wanted to watch the entire struct/array), I
expressed my concerns about overloading the meaning of that flag, and
about the possibility that if someone changes the way the lazy flag
behaves, it could break watchpoints.

I think we need a prominent comment near the declaration of the flag
which alerts people to this use.  I will add it.

> In valops.c & friends, the lazy flag is definitely used to indicate
> whether the data HAS been read in from inferior memory or not.

That is indeed its meaning.  The reason it works with watchpoints is
because parts of the value chain which are irrelevant for watching the
value are never read from memory, and so remain lazy in most cases.

> I don't yet understand how this all works enough to know whether
> this seeming overloading is actually a problem or not, though I
> agree that given how it is used for watchpoints, it is not as simple
> as I first thought.

If your change turns on the lazy flag for something that should never
be watched, or if that flag will be turned off (once the value is
re-read) before GDB gets to inserting watchpoints, then it's quite
possible that there is no problems with your change.

> Still digging...

Let me know if I can help you figure this out.  I broke a few teeth at
the time digging into this, even though I stood on the Shoulders of
Giants such as Jim Blandy and Michael Snyder... ;-)