Summary: | Give access to "hidden" tracepoints | ||
---|---|---|---|
Product: | systemtap | Reporter: | Josh Stone <jistone> |
Component: | tapsets | Assignee: | Frank Ch. Eigler <fche> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | wcohen |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Josh Stone
2009-10-07 20:51:11 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.) 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 I'm working on another approach that relies on extra header files installed with the -debuginfo packages. test commit 61f1a63 appears to handle nearly all cases. |