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


As Frank said, this is a good start.  But it's really only the tip of the
iceberg of what you'd want to be able to use watchpoints for in practice.
That is, it does only permanent locations known statically at translation.
The really exciting uses of watchpoints are more dynamic than that.

I haven't thought much about the syntax or exact semantics for the cases
I've had in mind.  The syntax I'll use here is just a strawman to get our
minds onto the subject.  I have a feeling that there will be other kinds of
probes that are dynamic in the same sense I mean here and that we might
want the syntax for such things to be generalized across more such cases,
but nothing else in particular is coming to mind right now.

What is often the most worthwhile use of a watchpoint looks like this:

	probe watch_foo(loc) = kernel.data(loc)
	{
	  printf("touched %s: %s\n", describe(loc), backtrace())
	}

	probe kernel.function("foo")
	{
	  foo_watchers[tid()] = enable watch_foo($ptrarg->val)
	}

	probe kernel.function.return("foo")
	{
	  disable foo_watchers[tid()]
	  delete foo_watchers[tid()]
	}

This is dynamic in the sense that we cannot place "probe watch_foo" until
we know the replacement for "loc", and that address is not knowable until
we actually hit the "foo" entry probe and compute it as "&ptrarg->val".

The use of the array is meant to indicate that there could be multiple
independent instances of "probe watch_foo" at any given time, on
different addresses.  Hence it's not just "enable watch_foo" and
"disable watch_foo", which could correlate with the probe predicate
thingy we already have.  I have no idea what the actual method for that
would be, or, if it looked like that, what the type of the value in
foo_watchers[tid()] would be.

The "describe(loc)" is meant to indicate the idea that the parameterization
might apply to more than simply the mechanics of probe placement itself.
I'm not sure whether you'd want it to resolve to "0x1234" (final address)
or to "$ptrarg->val" (symbolic value of the "loc" parameter).

It's also not entirely clear what things like pp() should mean inside
watch_foo.  It could be "watch_foo".  It could be "watch_foo(0x1234)".
It could be "watch_foo($ptrarg->val)".  Or, instead it could be
"kernel.function(\"foo\")", i.e. the context of the "master" probe.
Perhaps we want ways to refer to both those things.

Or perhaps all of that can just be done as:

	probe watch_foo(loc) = kernel.data(loc)
	{
	  printf("touched %s: %s\n", foo_desc[tid()], backtrace())
	}
	probe kernel.function("foo")
	{
	  foo_desc[tid()] = sprintf("%s:ptrarg->val in %d", pp(), tid())
	  foo_watchers[tid()] = enable watch_foo($ptrarg->val)
	}

(For the general case, you'd want to use something beyond plain tid() as
the index there, for multiple separate watch_foo's active in one thread.)

Also, note that while a given instance of "watch_foo" is in some sense
tied to its "master probe", the "watch_foo" probe itself is a "rootless"
probe like timer et al.  It can happen anywhere, so you can't statically
assume any $ context for it.

I don't really have much clue about what the right way is to tackle
these kinds of issues in the script language.  But I know that we want
to enable these kinds of uses eventually, and make them as conceptually
easy to use in a script as they are for a programmer to describe in
words (i.e. "Watch ptrarg->val inside foo calls.").  So someone needs to
think harder about what it all means.


Thanks,
Roland


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