This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Symbol resolution problem in stap on FC5


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).

> 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"?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]