Bug 10745 - Give access to "hidden" tracepoints
Summary: Give access to "hidden" tracepoints
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: tapsets (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Frank Ch. Eigler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-07 20:51 UTC by Josh Stone
Modified: 2010-10-20 17:16 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Stone 2009-10-07 20:51:11 UTC
By "hidden" I mean tracepoints which are not exposed in a usable header.  This
might be because the header is not in include/trace/ or otherwise not packaged
in kernel-devel, or even when it is present it might be dependent on some
subsystem-internals.

The only way I know to really discover *all* tracepoints is through debugfs on a
live kernel.  That requirement doesn't really fit our general usage model.

I'm thinking instead to expose these as kernel.trace("foo").raw, analogous to
the kprobe.function("foo") which does no name checking.  If you specify an
incorrect name, you just won't get any hits, but no harm is done.

It's possible to register a handler without knowing the full callback signature.
 Instead of register_trace_foo(handler), we could imitate what that inline
really does with tracepoint_probe_register("foo", (void*)handler).

We couldn't know any argument names/types this way, but exposing $arg1, $arg2,
etc. as longs might be enough to be usable with @cast.  However, that assumes
though that passing a foo_handler(long, long, ...) with an incorrect number of
parameters wouldn't do any harm.
Comment 1 Frank Ch. Eigler 2009-12-01 14:42:19 UTC
(In reply to comment #0)

> The only way I know to really discover *all* tracepoints is through debugfs on a
> live kernel.  That requirement doesn't really fit our general usage model.

Maybe we don't have to be too dogmatic about our usual method.  If we can eke
out a list of tracepoints from a running kernel, and use its running 
build-id/release to validate it against the target -r kernel, then the 
information can probably be relied upon.

(Of course, debugfs is sometimes not mounted.)
Comment 2 Frank Ch. Eigler 2010-03-18 21:29:31 UTC
This sort of thing should work at some point:

probe perf.type(2).config(NN)

where NN comes from /debugfs/tracing/events/*/*/id

We could supply a shell script to parse the latter directory to come up with
a tapset correct for the currently running kernel.  Or the translator could
do it, and store it cached based on kernel build-id or somesuch.

See also /proc/sys/kernel/perf_event_paranoid
Comment 3 Frank Ch. Eigler 2010-10-01 21:02:41 UTC
I'm working on another approach that relies on extra header files
installed with the -debuginfo packages.
Comment 4 Frank Ch. Eigler 2010-10-05 18:15:46 UTC
test
Comment 5 Frank Ch. Eigler 2010-10-20 17:16:37 UTC
commit 61f1a63 appears to handle nearly all cases.