Re: Changing the "enclosing_type" of a value structure

[Jim Ingham <jingham at apple dot com>]

on 8/15/00 11:20 PM, Eli Zaretskii at eliz@delorie.com wrote:

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

Would it be possible to break out the uses of lazy into two flags, a
"needs_fetching" flag to tell whether gdb needs to read the flag from the
inferior, and a "already_fetched"  flag, used if "needs_fetching" is true,
to indicate whether the data has been read in or not?  I don't think that we
are ever going to get & keep around so may struct value's that one more int
is a really big deal, and this would make the intent of the code a lot
clearer.

Then we could either pull the VALUE_LAZY test into the value_fetch_lazy, or
redefine the VALUE_LAZY macro to be (val)->needs_fetching &&
(val)->already_fetched.

This just seems lots less mysterious, at the expense of being a little more
verbose.  If you think this sounds like a good idea, I will whack it
together.

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

I agree with this, but the "quite possible" qualifier (which I also agree
with) makes me a bit nervous.

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

Cool, thanks.  I need to do some more investigations (mostly to raise my
level of cultural awareness), and then I may pester you with stupid
questions.

Jim
--
Jim Ingham                                            jingham@apple.com
Apple Computer, Inc.