[RFC] Systemtap translator support for hardware breakpoints on

[Prerna Saxena]

Hi Roland, Frank,

Thanks for the exhaustive review and nice suggestions. The discussion 
was spread across a multitude of emails -- I'm posting a summary of 
ideas on how to augment the hardware breakpoints with systemtap, with my 
understanding on how this could be implemented.

1. Probe points :
probe kernel.data(ADDRESS).write
probe kernel.data(ADDRESS).read
probe kernel.data(ADDRESS).change
probe kernel.data(ADDRESS).rw
	i) .read -this probe point probes read access ONLY to an address -- 
needs 2 debug registers on x86 : one for rw, and the other for write. 
Underlying implementation will need to check if DR6 flashes a hit for 
only the rw-based probe, and not the write probe -- in which case its a 
read request. I need to explore the existing hw breakpoint API better to 
implement this.
     ii.) write : probes write access to an address.
     iii.) change : checks every time a write request modifies the value 
at an address. It weeds out redundant writes that overwrite the location 
with same data and will execute only if the value at the specified 
address indeed undergoes a change.
	Roland had a cool suggestion for this. I was wondering if this can best 
be implemented in a tapset, that calls a .write probe underneath, with 
the correct semantics. Or is it better to enable the translator to emit 
such code.
	iv. rw : Coalescing handlers (by defining a common handler for both 
.read and .write request) is difficult. To implement this, far more 
intelligence needs to be built to check if probe handlers described in 
the script are identical or not -- I'll extend this later, for now ,I 
was wondering if this syntax may be retained for ease of use.

2. Script Optimizations if more hwbkpt requests are present in the 
script than the  hardware can support.
I'll add an elementary check that errors out if too many requests exist. 
(eg, more than 1 probe kernel.data on ppc or more than 4 such probes on 
x86 )

3. probe kernel.data($variable).write { ... }
Nice suggestion again ! The translator can be augmented to use this, and 
add dwarf lookup for $variable.

4. probe kernel.data(0x12c).write.length(4)
For now, ppc patches are not done, but I was planning to allow this as a 
valid construct.
For ppc, any length upto 8 is acceptable. IIRC, the hwbkpt kernel API 
takes care of filtering a hit if the defined hwbkpt probe has a separate 
address interval and the hit is at an address which is outside that 
interval. (I need to check its implementation with hw breakpoint kernel 
API).

5. Dealing with invalid requests, eg :

i)    probe kernel.data(0x120).length(8) on x86
translator intelligence to split an invalid request into valid pieces 
will turn it into a case like :
     probe kernel.data(0x120).length(4),
	  kernel.data(0x124).length(4)
     --> This is doable. But, is it not still easier for this to error 
out, prompting the user about supported lengths on that arch ? the user 
can then place a more appropriate probe which matches a narrower address 
interval of interest ? This conserves scarce resource like debug regs.

ii) Another case of invalid requests on x86 :
     probe kernel.data(0x120).length(3)
     this can be dealt with, by approximating the length to the next 
allowable size, such as placing a request for hwbkpt of length 4 bytes here.
I will edit the existing patch to allow translator to approximate the 
request to a bigger address interval instead of invalidating the 
request, as its done now.

6. Dynamic enabling/disabling of a hardware breakpoint from kprobe 
handler context , AND enabling a hardware breakpoint within a function:
	I am not sure of how to implement this, since kprobe handlers run in 
exception context. I'm trying to understand how this can be done, will 
send out an update asap.

Looking forward to more interesting possibilities of how we can exploit 
hardware breakpoints better with systemtap..

Regards,

-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India