This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: How to track the functions in self-written module using SystemTap?
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Nan Xiao <xiaonan830818 at gmail dot com>
- Cc: David Smith <dsmith at redhat dot com>, systemtap at sourceware dot org
- Date: Tue, 08 Dec 2015 14:41:13 -0500
- Subject: Re: How to track the functions in self-written module using SystemTap?
- Authentication-results: sourceware.org; auth=none
- References: <CA+MhoaPMSTgpHCDjNhwcDkMaLryLy+F6tH6HNcrvDDF9bEbBbg at mail dot gmail dot com> <564CD3C1 dot 2090900 at redhat dot com> <CA+MhoaPxCC1_CH86A7SuXaoNEJyzaRvv2wpha8shF4V8T9WeOQ at mail dot gmail dot com> <CA+MhoaPGgWuVCEnW8p6cvbN_6qFE1jeDjz+pYtDuCbL00b5Ong at mail dot gmail dot com> <564DE376 dot 3020104 at redhat dot com> <CA+MhoaPCnkDp=A8KD19g1J+Gu91Z=+re09i8xgbg8=DW++uegQ at mail dot gmail dot com> <565CC50B dot 90104 at redhat dot com> <CA+MhoaPHi6ORfgTtWu_Z09zLAcgaAEPO10vWFi1kNhvsS5V0Ow at mail dot gmail dot com> <y0mk2oync6p dot fsf at fche dot csb> <CA+MhoaO9kbLCWJ4S3jSGxW2gr=TW8fGhZ8znG5pX5dXzLLoh6Q at mail dot gmail dot com> <565DCA83 dot 6040102 at redhat dot com> <CA+MhoaOc18xQ0aa4e7uiKwVy6oEwHs-1GuP3pPPLyNtXyQA2nQ at mail dot gmail dot com> <565F65D4 dot 4050005 at redhat dot com> <CA+MhoaOQEgOe_b-wdY-qbWPCgPdFdN2WkvMTU-L7c9W1bZs8pw at mail dot gmail dot com> <566075FA dot 40207 at redhat dot com> <CA+MhoaPeuEgwv9VQ85yYtXs9Nq-hFDR 634eAurryVHUbPvA4zw at mail dot gmail dot com> <566183E6 dot 9050101 at redhat dot com> <CA+MhoaPcgbu0NNWMHXsvx3movVMdCN+09q65Swe++XjQ_2d4NQ at mail dot gmail dot com> <5665E3CC dot 6000104 at redhat dot com> <CA+MhoaMb=ry4tPZ2Pt+mNHPjsKGwSaCofzxku8PqLKTXynjxiQ at mail dot gmail dot com>
Nan Xiao <xiaonan830818@gmail.com> writes:
> [...]
>>> # stap -d /root/kernel/105.ops/kex.ko -v -e 'probe
>>> module("/root/kernel/105.ops/kex.ko").function("*") { printf("%s\n",
>>> print_backtrace()) }'
>>> [...]
>>> 2280usr/540sys/5099real ms.
>>> Pass 5: starting run.
>>> WARNING: no or bad debug frame hdr
>>> WARNING: No binary search table for debug frame, doing slow linear
>>> search for /root/kernel/105.ops/kex.ko
I wonder if something is going wrong with the module pathname logic.
Could you try a few more things?
- installing kex.ko under the kernel install tree (probably
/lib/modules/`uname -r`/kernel or similar), so that
stap -d kex -e 'probe module("kex").... {}'
works (without the path name).
- running stap in save-temp-directory (-k) mode, and shipping
us a tarball of the /tmp/XXX directory, to see specifically
how the stap-symbols.h file looks. (email direct rather than
to the mailing list; this file may be big)
- running stap in -DDEBUG_UNWIND=2 mode to get lots of
backtracing-related data
- FChE