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


On Thu, Jan 07, 2010 at 02:38:41PM -0800, Roland McGrath wrote:
> 
> probe kernel.data(0x1234).write { one_thing() }
> probe kernel.data(0x1234).read { another_thing() }
> 
> you cannot consolidate these into one RW breakpoint, because you
> won't know which handler to run.  This is in contrast to e.g. two
> kprobes at the same PC.  Those you can consolidate at translation
> time so the module init code only inserts one kprobe and its handler
> does both things.
> 
> Even for the same_stuff() case, it's not clear you can really 
> consolidate them if something like pp() is used.  i.e., where the
> name of the specific probe is part of the "stuff", it's not really
> the same stuff any more.
> 
> On x86 you can distinguish this by just using two different debug
> registers, one for the read and one for the write.  You can tell
> which of the two hit.  Only if you don't care to distinguish them
> can you use a single debug register set to RW.

On x86, you imply something akin to using one debug register monitoring
"write" and the other monitoring "rw" for the same address, right?

We did try this sometime back. The event does trigger an (one) exception
and the only way to distinguish whether a 'read' happened is to look
at the debug status register (DR6) and see if one or both bits are set,
and take appropriate action.

Maybe, a better way to do it is to hide this complexity by stap taking
care of using 2 DRs underneath -- but there is no ironclad gurantee that
2 free debug registers are available for stap's use at all times.

Ananth


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