This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Symbol resolution problem in stap on FC5
- From: srinivasa <srinivasa at in dot ibm dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Tue, 02 May 2006 19:46:47 +0530
- Subject: Re: Symbol resolution problem in stap on FC5
- Organization: IBM
- References: <444E58D4.9000906@in.ibm.com> <y0mu08g9yts.fsf@ton.toronto.redhat.com>
Frank Ch. Eigler wrote:
srinivasa@in.ibm.com wrote (in two separate messages):
probe kernel.statement("sys_open") {
printf("hi\n");
[...]
char const * dwarf_kprobe_probe_0_location_names[1] = {
"kernel.function(\"sys_open@fs/open.c:1089\")"
};
Note that there is already a separate bug there. When you specify
"kernel.statement()", systemtap should probe the address nearest the
statement, not the logical function entry. So, in this case, it
should not look for a prologue at all (new bug #2608).
No,script fails even if I specify "kernel.function()".
=================================
[root@localhost stap]# cat open.stp
probe kernel.function("sys_open") {
printf("hi\n");
}
=====================================
[root@localhost stap]# stap -vvvv open.stp
Created temporary directory "/tmp/stap78fhtA"
Searched
'/usr/local/share/systemtap/tapset/2.6.15-1.2054_FC5/i686/*.stp', match
count 0
Searched '/usr/local/share/systemtap/tapset/2.6.15-1.2054_FC5/*.stp',
match count 0
Searched '/usr/local/share/systemtap/tapset/2.6.15/i686/*.stp', match
count 0
Searched '/usr/local/share/systemtap/tapset/2.6.15/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6/i686/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/i686/*.stp', match count 1
Searched '/usr/local/share/systemtap/tapset/*.stp', match count 15
Pass 1: parsed user script and 16 library script(s) in
100usr/0sys/138real ms.
parsed 'sys_open' -> func 'sys_open'
pattern 'kernel' matches module 'kernel'
focused on module 'kernel' = [c0100000-c041efdc, bias 0]
pattern 'sys_open' matches function 'sys_open'
selected function sys_open
prologue searching function 'sys_open' 0xc0151313-0xc015132d@fs/open.c:1089
checking line record 0xc0151313@fs/open.c:1093
prologue found function 'sys_open' (naked) = 0xc0151313
probe sys_open@fs/open.c:1089 pc=0xc0151313
=================================================
static struct kprobe dwarf_kprobe_probe_0[1]= {
{.addr= (void *) 0xc0151313}
};
char const * dwarf_kprobe_probe_0_location_names[1] = {
"kernel.function(\"sys_open@fs/open.c:1089\")"
============================================
[root@localhost stap]# cat /proc/kallsyms | grep sys_open
c0152074 T do_sys_open
c015211e T sys_openat
c0152139 T sys_open
=================================================
Searched '/usr/local/share/systemtap/tapset/2.6.15-1.2054_FC5/i686/*.stp',
[...]
parsed 'sys_open' -> func 'sys_open'
focused on module 'kernel' = [c0100000-c041efdc, bias 0]
[...]
prologue searching function 'sys_open' 0xc0151313-0xc015132d@fs/open.c:1089
checking line record 0xc0151313@fs/open.c:1093
prologue found function 'sys_open' (naked) = 0xc0151313
probe sys_open@fs/open.c:1089 pc=0xc0151313
The only thing that occurs to me is that perhaps your running kernel
and your debuginfo have a slight version mismatch. Is your "uname -r"
exactly "2.6.15-1.2054_FC5"?
I also doubt the samething,but it looks both are having same version.
===============
[root@localhost stap]# uname -r
2.6.15-1.2054_FC5
====================
[root@localhost stap]# rpm -qa | grep kernel
kernel-debuginfo-2.6.15-1.2054_FC5
kernel-smp-devel-2.6.15-1.2054_FC5
kernel-devel-2.6.15-1.2054_FC5
kernel-smp-2.6.15-1.2054_FC5
kernel-2.6.15-1.2054_FC5
===================================
At this time, systemtap does not emit any additional version-related
checking logic, so if modprobe lets slight drifts through, we don't
detect it. If this is really happening, we need to fix it.
- FChE