This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][Patch 0/2] New Probe family : probe kprobe.function()
- From: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>
- To: fche at redhat dot com (Frank Ch. Eigler)
- Cc: Prerna Saxena <prerna at linux dot vnet dot ibm dot com>, systemtap at sourceware dot org
- Date: Thu, 16 Apr 2009 22:27:55 +0530
- Subject: Re: [RFC][Patch 0/2] New Probe family : probe kprobe.function()
- References: <49E724C5.2070904@linux.vnet.ibm.com> <y0m4owoh7dg.fsf@ton.toronto.redhat.com>
- Reply-to: ananth at in dot ibm dot com
On Thu, Apr 16, 2009 at 12:48:43PM -0400, Frank Ch. Eigler wrote:
>
> Prerna Saxena <prerna@linux.vnet.ibm.com> writes:
>
> To what extent does the kernel's symbolic kprobe logic allow probes to
> be placed within modules?
There is no difference in logic between probes in modules vs. those in
kernel - both just work since the kallsyms_lookup_name() calls into
module_kallsyms_lookup_name() if the symbol wasn't resolved in the
kernel.
However, namespace clashes are allowed in modules. AFAICS if there is a
namespace clash, the first resolved address is returned. To mitigate
this, one can use <module>:<symbol>.
> Would it be worthwhile to allow numeric
> probe addresses (as in kernel.statement(0xaddr).absolute)?
That would be even more straightforward I think - just set the emitted
kp.addr = 0xaddr
Ananth