This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Stap is translating to functions in __exit sections...and later module load fails
- From: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, Systemtap <systemtap at sources dot redhat dot com>
- Date: Fri, 13 Oct 2006 13:50:47 -0700
- Subject: Re: Stap is translating to functions in __exit sections...and later module load fails
- References: <C56DB814FAA30B418C75310AC4BB279DC4C745@scsmsx413.amr.corp.intel.com>
- Reply-to: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
On Fri, Oct 13, 2006 at 02:02:39PM -0700, Stone, Joshua I wrote:
> On Friday, October 13, 2006 1:26 PM, Keshavamurthy, Anil S wrote:
> > stap -e 'probe kernel.function("*") { log("."); }'
> > results in
> > ERROR: dwarf probe
> > kernel.function("exit_pfm_fs@arch/ia64/kernel/perfmon.c:1507")
> > registration failed, rc=1
> >
> > Looks like on Ia64, stap is translating to functions which are in
> > __exit sections, as in the above failure case exit_pfm_fs() function
> > is prefixed with __exit and when the module is loaded the
> > kprobe registration fails as the functions in exit sections no longer
> > exist.
>
> The translator blacklist tries to avoid such functions by checking the
> section name -- anything within a section beginning with '.exit.' (e.g.,
> .exit.text) is blacklisted, and thus won't match a function("*").
Exactly, I expected that the translator blacklists' and does not
elaborate such functions. But looks like this is not happening.
See here....
#stap -p2 -e 'probe kernel.function("*") {}' | sort | uniq |grep exit_pfm_fs
kernel.function("exit_pfm_fs@arch/ia64/kernel/perfmon.c:1507"),
# cat /proc/kallsyms |grep exit_pfm_fs
#
#
>
> Does IA64 do something different with the __exit sections?
>
Everything in __exit sections will be discarded just after boot.
-thanks,
Anil