Re: [PATCH 2/4] Hardware accelerated watchpoint conditions

["Ulrich Weigand" <uweigand@de.ibm.com>]

Thiago Jung Bauermann wrote:

> I changed the comment to read:
> 
> /* Return non-zero if the target is capable of using hardware to evaluate
>    the condition expression.  In this case, if the condition is false when
>    the watched memory location changes, execution may continue without the
>    debugger being notified.
> 
>    Due to limitations in the hardware implementation, it may be capable of
>    avoiding triggering the watchpoint in some cases where the condition
>    expression is false, but may report some false positives as well.
>    For this reason, GDB will still evaluate the condition expression when
>    the watchpoint triggers.  */
> 
> What do you think?

Looks good to me.

> > > +  for (; v; v = value_next (v))
> > > +    {
> > > +      if (VALUE_LVAL (v) == lval_memory)
> > > +	{
> > > +	  /* A lazy memory lvalue is one that GDB never needed to fetch;
> > > +	     we either just used its address (e.g., `a' in `a.b') or
> > > +	     we never needed it at all (e.g., `a' in `a,b').  */
> > > +	  if (!value_lazy (v))
> > > +	    found_memory_cnt++;
> > > +	}
> > > +      else if (VALUE_LVAL (v) != not_lval
> > > +	       && deprecated_value_modifiable (v) == 0)
> > > +	return -1;	/* ??? What does this represent? */
> > 
> > These are values from the history (e.g. $1).  In this context, they
> > should be treated as non-lvalues, so they should be fine ...
> 
> I removed that else if then. I'll submit a separate patch to replace
> that comment in can_use_hardware_watchpoint.

Actually, thinking about this a bit more, the logic still does not
seem quite correct.  What we really want is:

- not_lval values: these are fine
- deprecated_value_modifiable (v) == 0 (history) values: treat just
  like not_lval, no matter what their VALUE_LVAL says
- lval_memory values: check whether they are lazy or not and count them
- all other values (lval_computed, lval_internalvar ...): *not* OK

In particular, the missing check on lval_computed may become more important
now that DWARF multi-piece values are always represented as lval_computed ...
(This may also affect watchpoint code in breakpoint.c, but I guess that's
a different issue.)

> 2010-07-01  Sergio Durigan Junior  <sergiodj@linux.vnet.ibm.com>
> 	    Thiago Jung Bauermann  <bauerman@br.ibm.com>
> 
> 	* breakpoint.c (fetch_watchpoint_value): Rename to fetch_subexp_value
> 	and move to eval.c.  Change callers.
> 	(insert_bp_location): Pass watchpoint condition in
> 	target_insert_watchpoint.
> 	(remove_breakpoint_1) Pass watchpoint condition in
> 	target_remove_watchpoint.
> 	(watchpoint_locations_match): Call
> 	target_can_accel_watchpoint_condition.
> 	* eval.c: Include wrapper.h.
> 	(fetch_subexp_value): Moved from breakpoint.c.
> 	* ppc-linux-nat.c (ppc_linux_region_ok_for_hw_watchpoint):
> 	Formatting fix.
> 	(can_use_watchpoint_cond_accel): New function.
> 	(calculate_dvc): Likewise.
> 	(num_memory_accesses): Likewise.
> 	(check_condition): Likewise.
> 	(ppc_linux_can_accel_watchpoint_condition): Likewise
> 	(ppc_linux_insert_watchpoint): Call can_use_watchpoint_cond_accel,
> 	check_condition and calculate_dvc.
> 	(ppc_linux_remove_watchpoint): Likewise.
> 	(_initialize_ppc_linux_nat): Set to_can_accel_watchpoint_condition to
> 	ppc_linux_can_accel_watchpoint_condition
> 	* target.c (debug_to_insert_watchpoint): Add argument for watchpoint
> 	condition.
> 	(debug_to_remove_watchpoint): Likewise.
> 	(debug_to_can_accel_watchpoint_condition): New function.
> 	(update_current_target): Set to_can_accel_watchpoint_condition.
> 	(setup_target_debug): Set to_can_accel_watchpoint_condition.
> 	* target.h: Add opaque declaration for struct expression.
> 	(struct target_ops) <to_insert_watchpoint>,
> 	<to_remove_watchpoint>: Add new arguments to pass the watchpoint
> 	<to_can_accel_watchpoint_condition>: New member.
> 	condition.  Update all callers and implementations.
> 	(target_can_accel_watchpoint_condition): New macro.
> 	* value.c (free_value_chain): New function.
> 	* value.h (fetch_subexp_value): New prototype.
> 	(free_value_chain): Likewise.

Except for the num_memory_accesses logic discussed above, the patch
is otherwise OK now.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com