Re: Symbol resolution problem in stap on FC5

[srinivasa <srinivasa at in dot ibm dot 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
>