[Bug translator/6921] New: tracepoint support

[Bug translator/6921] New: tracepoint support

[fche at redhat dot com]

2.6.26+ have something called tracepoints.  See include/linux/tracepoint.h,
DEFINE_TRACE() macro.  It's desirable to let systemtap hook up to these things
directly, without marker intermediaries.  Thanks to a tip from roland, here's
how it might be done ...

 so ... we have DEFINE_TRACE declaring the static inline fn that should have the
same prototype as the final tracepoint callback function
 so we could do a dwarf search on the putative tracepoint name "foo" to find a
inline function "trace_foo"
 and/or use the tracepoint string section table to validate the "foo" name
 then look up its formal parameters in dwarf
 then save any particular inlined instance pc for later $param resolution
 then emit a tracepoint callback api thing with the same signature

$param resolution is tricky, since we wouldn't be using dwarf location list
data in a real tracepoint callback function.  we'd emit the callback function.
So for mapping $expr->field1->field2, we may *validate* the expression using
dwarf type data (including "alternatives" listing), but we'd just emit C code
that transcribes $expr->field1->field2 to "expr->field1->field2". ... Except
for pointer value checking .. so we may need to expand it to kread() chains
as for dwarf/pt_regs based probes.

The end result would be a generic tracepoint attachment mechanism that gives
good performance and good access to parameters.

-- 
           Summary: tracepoint support
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6921

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6921] tracepoint support

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-09-29 23:35 -------
One extra complication for bonus points ... since the 
tracepoint interface function that we emit has to carry
all the parameter types in their native C beauty, we need
to make sure that all the needed #include's will be added
so that the C compiler will accept them.  So while we
process the $expr->field1->field2 expressions, we also
need to record which file each referenced type was
declared in (should be there in dwarf), process it slightly
(to cut off any full path name before ".../include/linux"),
then remember to spit out a #include for each of them.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6921

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6921] tracepoint support

[tytso at mit dot edu]

------- Additional Comments From tytso at mit dot edu  2009-01-05 15:42 -------
Note that various kernel markers have started disappearing from the kernel in
favor of tracepoints starting in 2.6.27 and 2.6.28....  in particular all of the
kernel scheduler markers have disappeared, and the only markers left in generic
kernel code are in the kvm and ext4 subsystems.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6921

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6921] tracepoint support

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-02-21 00:50 -------
I think we could compile a tiny kernel module to query the available
tracepoints.  Something like:

Makefile:
EXTRA_CFLAGS := -g
obj-m := tracequery.o

tracequery.c:
#include <linux/module.h>
#include <linux/tracepoint.h>

// override the declaration macro to synthesize some probe functions
#undef DECLARE_TRACE
#define DECLARE_TRACE(name, proto, args) void stapprobe_##name(proto) {}

// dynamically pull in all tracepoint headers from include/trace/
#include <trace/block.h>
#include <trace/boot.h> // <- not actually a tracepoint, but oh well
#include <trace/sched.h>

int init_module(void) { return 0; }
void cleanup_module(void) { }
MODULE_DESCRIPTION("tracepoint query");
MODULE_LICENSE("GPL");


This gives us a module which we can scan for stapprobe_foo tracepoints.  We also
get all the local debuginfo we want without relying on the dreaded
kernel-debuginfo packages.

Thoughts?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6921

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6921] tracepoint support

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-21 15:11 -------
What a clever idea to hijack the DECLARE_TRACE() macro 
to generate something else.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |jistone at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=6921

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.