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 Fri, Jan 08, 2010 at 02:24:02AM -0800, Roland McGrath wrote:
> > On x86, you imply something akin to using one debug register monitoring
> > "write" and the other monitoring "rw" for the same address, right?
> 
> 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.
> 
> Right, that's what I meant.
> 
> > Maybe, a better way to do it is to hide this complexity by stap taking
> > care of using 2 DRs underneath -- 
> 
> That's exactly what I was suggesting.
> 
> > but there is no ironclad gurantee that
> > 2 free debug registers are available for stap's use at all times.
> 
> Indeed, nor that there is one.
>

An easier (and less accurate, but more conservative with debug register
use) method to distinguish a .read (from a .write) in x86 would be to use
your suggested .change semantics. i.e.

Inside a hw-breakpoint exception, whenever "old_value == new_value", we
could interpret it as a .read (albeit inaccurately) operation.

Assuming that .write operations which re-write old_value will be fewer
in number, such a scheme would be really helpful; more so in debugging
context (although less-useful for read/write profiling).

Thanks,
K.Prasad


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