[rfc] Allow watchpoints on inaccessible memory

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Tue, Aug 21, 2007 at 09:33:28AM -0700, Jim Blandy wrote:
>> One thing I don't understand: why are the "always watch the outermost
>> value even if it is lazy" changes needed?  The code that evaluates the
>> watchpoint condition should always simply unlazy the expression's
>> final value to begin with, so it'll never be lazy by the time the
>> other code sees it.
>
> But that might fail.  That's why I switched from value_fetch_lazy to
> gdb_value_fetch_lazy, which catches exceptiosn.  Consider "watch *0";
> evaluating the expression works fine, but fetching the result of
> evaluate_expression will call memory_error.  We still want to set
> the watchpoint.

Okay, I see.

So there are actually two independent changes here:

- Even when we can't unlazy the final value of an expression, we may
  be able to set a hardware watchpoint on it, because hardware
  watchpoints don't require the address being watched to actually be
  accessible.

- When evaluating an expression to yield even a lazy a result fails,
  we can treat the fact of failure as a distinct value, and watch for
  that to change.

This change could be generalized, although I'm not sure it's worth it.
In evaluating an expression like p->q->r->s, if p->q is an invalid
address, we could set a hardware watchpoint on p->q.  In other words,
watching the values produced by a failing expression up to the point
of failure would allow us to use hardware watchpoints whenever
possible.  As it stands, your patch will record NULL as that
watchpoint's value, and single-step to watch for changes.

A lot of this rationale was not obvious to me by a long shot; I spent
about an hour working it all out.  I think the patch needs more
comments.  If you'd like me to write them, just say the word; I like
writing docs.