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: fche at redhat dot com (Frank Ch. Eigler)
- To: srinivasa <srinivasa at in dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 26 Apr 2006 10:49:19 -0400
- Subject: Re: Symbol resolution problem in stap on FC5
- References: <444E58D4.9000906@in.ibm.com>
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