Currently in rawhide, the ext4 tracepoint header has some naughty "../../.." includes, which makes the header unusable from the kernel-devel package. (See Red Hat bz512478). Since we build the tracepoint query in a single CU, any failure means that we won't find any tracepoints at all. :(
My plan is to build a separate tracepoint query module for each header, so there's no one point of failure. That will take more time to build in pass-2, but the modules are cached independently of the user's script. Hopefully the one-time penalty will be acceptable. The bonus is that this should make it easier to notice when the tracepoint headers have changed, and we can also throw in support for external tracepoint headers (e.g. in an out-of-tree kernel module).
commit f982c59b
Does stap actually need those ext4 headers to be present? They are needed so that TP_fast_assign() can fill in the event structure --- but I suspect that if they were edited out, or zero-length files dropped in place, stap would actually work correctly. If so, maybe we can figure out some particular #ifdef around the #include's for stap's benefits.
We actually ignore the TP_fast_assign, so the only real problems are the "struct ext4_foo*" parameters in the TP_PROTO. The compiler complains about a struct being declared in the parameter list when we try to define the proper callback. I think it should work to #ifdef the relative #includes and provide "struct ext4_foo;" declaration stubs instead. TRACE_HEADER_MULTI_READ might be a good key for this. Or, just provide the stubs and move the #includes up to the ext4 sources where they're needed (e.g. in super.c near CREATE_TRACE_POINTS).