This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

hardware breakpoints & watchpoint; was: TARGET_REGION_OK_FOR_HW_WATCHPOINT in target vector


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

best regards,
Marko


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]