Re: hardware breakpoints & watchpoint; was: TARGET_REGION_OK_FOR_HW_WATCHPOINTin target vector

[Andrew Cagney <ac131313 at redhat dot com>]

> On Friday 20 September 2002 03:39, Andrew Cagney wrote:
>
> > Hello,
> >
> > The macro TARGET_REGION_OK_FOR_HW_WATCHPOINT() needs to be moved to the
> > target vector.
> >
> > As part of this, I'd like to propose that its behavour be modified
> > slightly.  Instead of returning non-zero to indicate that the vaddr:len
> > is ok, it return the number of h/w watchpoint resources that are needed
> > to watch vaddr:len.
> Our architecture has more complex resource scheme, that cannot be observed 
> just by numbering.
>
> Since I do not know enough to propose direct improvements, I would like to 
> shortly describe our architecture. It handles hw breakpoints/watchpoint in 
> the following way:
> Debug unit has up to 8 matchpoints.
> A matchpoint is determined by:
>  * binary operator: signed/unsigned <, <=, ==, !=, >=, >, mask (bitwise AND)
>  * right operand is always 32bit/64bit constant
[Deja-vu:  I think I've seen similar asked of before.]

>  * left operand is one of:
> 	- instruction fetch EA (effective address), 
> 	- load EA
> 	- store EA
> 	- store data
> 	- load data
> 	- load or store EA
> 	- load or store data

>  * matchpoints can be chained together with || or && operators. It is very 
> important that they have same priority in our case!!!):
> same priority means: (...((data1 op1 const1) chain_op1 (data2 op2 const2)) 
> chain_op2 (data3 op3 const3)...
>
> e.g. $SEA == myvar && $SDATA == 5 is a watchpoint, which stops the CPU, when 
> value 5 is written to myvar.
>
> or more complex one:
> ($LEA == my_var)&&($LDATA < 50)||($SEA == my_var)&&($SDATA >= 50).
>
> Currently our gdb implementation include parser and optimizator for such 
> expressions, so truly almost everything can be written.
>
> * The above expressions can stop the cpu, start trace, stop trace or record 
> specified data into HW trace
>
> We needed to add special instruction, to handle such complex expression 
> grammar and to allocate matchpoints accordingly.
>
> It would be nice if we could create evironment common enough that all our 
> special functionality would be included with hopefully very simple user 
> interface.
GDB handles watchpoints performing the transformations:

	- string
	- expression tree
	- list of values to watch

I think the ``correct fix'' is for GDB's watchpoint code to be enhanced 
to do the operations you describe.  A guess is to, instead of transform 
the expression tree into a list of values.  Some how optomize the 
expression tree directly.

Andrew