From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71115 invoked by alias); 6 Jan 2016 21:55:28 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 71029 invoked by uid 48); 6 Jan 2016 21:55:24 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/19396] systemtap can't find certain kernel tracepoints Date: Wed, 06 Jan 2016 21:55:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2016-q1/txt/msg00006.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D19396 --- Comment #3 from David Smith --- >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("*")' =3D=3D=3D=3D Processing tracepoint header /lib/modules/2.6.32-573.el6.i686/build/include/trace/events/fence.h with qu= ery /tmp/stapi1JkQY/tracequery_kmod_1/tracequery_kmod_1_9.c =3D=3D=3D=3D If I run nm on the resulting .o file, I get: =3D=3D=3D=3D # 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 =3D=3D=3D=3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.