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


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

That's a thought.  I'm a stickler for not lying implicitly about what the
semantics are.  So I'd go for this being a .nonchange alongside .change,
described as "access without change" rather than calling it .read when it's
not.  If only powerpc can support a true .read low-level probe with the
semantics the name implies, then so be it--let the translator refuse to
perform .read on x86.

I think it's fine to have .read/.write/.rw be a low-level layer of probes.
(Perhaps even name them more obscurely.)  Make .change and .access be the
high-level probes that people normally use in scripts.

Btw, for a built-in .change it would be handy to give $$old and $$new or
somesuch magic bindings for the probe's script code to see the pre-change
and post-change values.  (You can of course track it yourself in script
variables, but that becomes error-prone boilerplate, while the .change
machinery will have it on hand under the covers anyway.)

OTOH, everything supports .write and that is probably what people would
actually use most.  So this may all be more thought than is really required.


Thanks,
Roland


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