[Bug translator/19396] systemtap can't find certain kernel tracepoints

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19396

--- Comment #3 from David Smith <dsmith at redhat dot com> ---
>From looking at the .o files produced when we're looking for tracepoints, I now
see a bit more at what is going on. For example, looking at
include/trace/events/fence.h, stap builds tracequery_kmod_1_9.c.  Here's the
line from the output of the following command:

stap -k --poison-cache --vp 090 -L 'kernel.trace("*")'

====
Processing tracepoint header
/lib/modules/2.6.32-573.el6.i686/build/include/trace/events/fence.h with query
/tmp/stapi1JkQY/tracequery_kmod_1/tracequery_kmod_1_9.c
====

If I run nm on the resulting .o file, I get:

====
# nm tracequery_kmod_1_9.o
00000000 R stap_trace_system
00000050 T stapprobe_fence_annotate_wait_on
00000080 T stapprobe_fence_destroy
00000060 T stapprobe_fence_emit
00000090 T stapprobe_fence_enable_signal
00000070 T stapprobe_fence_init
000000a0 T stapprobe_fence_signaled
000000c0 T stapprobe_fence_wait_end
000000b0 T stapprobe_fence_wait_start
00000010 T stapprobe_module_free
00000020 T stapprobe_module_get
00000000 T stapprobe_module_load
00000030 T stapprobe_module_put
00000040 T stapprobe_module_request
====

So, the reason why I can look up the module tracepoints as if they were in the
'fence' subsystem is that they are getting included in the fence.h query
module.

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