This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap 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]

Re: [RFC] Systemtap translator support for hardware breakpoints on


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


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