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

[Roland McGrath <roland at redhat dot com>]

Another thing to note is that hw_breakpoint registrations can fail at
runtime for "normal" reasons.  The hardware watchpoints are a scarce global
resource (4 on x86, only 1 on powerpc).

The translator might encode some per-arch assumptions about the known
kernel implementation and so give you a warning/error if your script as
elaborated statically requires more registrations than the kernel ever
supports (i.e. more than 4 on x86, more than 1 on powerpc).

But even if you only use one, it might not be free at runtime.  What I
presume your code does is just fail module initialization if registration
fails, so staprun just fails quickly and never even tries to run the
script.

Here's an idea for being fancier:

	probe kernel.data($foo).change { ... }
	probe kernel.data($foo).change.unavailable {
	  pred = 1
	  println("NOTE: watchpt not available, using plan B")
	}

	probe kernel.function("foo1") if pred { ... }
	probe kernel.function("foo2") if pred { ... }
	probe kernel.function("foo3") if pred { ... }

If there is no .unavailable probe given for some watchpoint probe, then
the default is to fail at initialization time.  If there is one, it acts
like a .begin probe.

That brings up a similar tangential idea.  If we have the dynamic
watchpoint probes in some form, then:

	probe watch_foo(loc) = .data(loc).change { ... }
	probe watch_foo(loc) = .data(loc).change.begin { ... }
	probe watch_foo(loc) = .data(loc).change.end { ... }

Those .begin and .end would run when "enable watch_foo" and "disable
watch_foo" happens.  The idea is that a tapset could define watch_foo
for watching a particular kind of thing in some fancy way, and then use
these to initialize and destroy elements in global state arrays it might
keep for each watchpoint instance to use across multiple changes to the
same variable.  For example, when watching a pointer variable you could
be tracking in some tapset-global array of used/live pointers of that
sort.

On a tangent of that tangent, here I've used .data(...) with a leading
. to mean "in the context of the enabling probe".  If it's an instance
of 'enable watch_foo' in 'probe kernel.foo' then it means kernel.data,
if in 'probe module("xyz").foo' it means module("xyz").data, etc.
Really, you could say that context is part of "loc" and it doesn't make
sense for the static spec of a dynamic probe schema ever to indicate an
absolute context.


Thanks,
Roland