Re: Code in can_use_hardware_watchpoint()

[Michael Snyder <msnyder@cygnus.com>]

J.T. Conklin wrote:
> I not sure what 'v->lval != not_lval && v->modifiable == 0' is trying
> to catch.  I put a breakpoint at can_use_hardware_watchpoint(), tried
> every sort of watch expression I could expect, and only found nodes
> with v->lval == lval_memory, v->lval == lval_register, and v->lval ==
> not_lval && v->modifiable == 0.  Because I didn't see anything that
> tripped that expression, I thought that it might contain a bug.  If
> not, it's in desparate need of a comment...
> 
> When I suggested changing the expression to 'v->lval != not_lval &&
> v->modifiable == 1', I was thinking that anything that's modifiable
> that isn't in memory should be rejected.
> 
> I thought that a catch all expression might be better in case new
> value types are added.  In fact, it looks like lval_reg_frame_relative
> types should be rejected one way or the other now.

OK, I'm going to add your lval_register change, and
Eli Zaretskii's change that rejects any expression that
contains a memory sub-expression that isn't watchable.

I have a gnawing suspicion that there are other cases we're
overlooking, so if you or anyone else wants to continue to
analyze this, feel free.  The original version of this function
rejected any expression contiing a subexpression that was not
an lval -- but I would hate to go back to that.  That would
mean that expressions such as:
	watch xyz + 123
would be rejected.  There's no reason to reject this expression,
since xyz can be watched and 123 will not change.

				Michael