By "man stapprobes" command, there is syntax:
probe kernel function("@kernel/sched.c")
It will probe all the function in sched.c, but I never use this syntax. And I will try it.
>From: [hidden email] [mailto:[hidden email]]
>On Behalf Of Keshavamurthy, Anil S
>Sent: 2005年12月9日 9:04
>To: [hidden email] >Subject: How to express in systemtap?
>I am trying to insert probes on all functions belonging to a particular
>For example, say I want to insert the probes on all functions in the
>__sched_text_start and __sched_text_end range.
>How can I express this in systemtap?
>Sr. Software Engineer
>Open Source Technology Center/SSG
> I am trying to insert probes on all functions belonging to a particular
We do not have any selectors like this at the moment, unless I missed some.
The expressive probe selectors we have are mostly in terms of source code
rather than binary level details. (There is "literal PC", but that is not
> For example, say I want to insert the probes on all functions in the
> address range
> __sched_text_start and __sched_text_end range.
> How can I express this in systemtap?
AFAIK the best you can do at the moment is either to approximate it by hand
with source-based selectors (i.e., know that they are all in *sched*.c or
the functions are all named *sched* or whatever), or approximate it by hand
by finding the functions in that range by external means and supplying
those function names or addresses.
Here's an idea for an extension to let you express this easily:
That is, an optional subclause on probe types that yield PC addresses for
.pc(RANGE [, RANGE ...])
where RANGE can be: PC or PC .. PC, and PC can be an integer literal
address, or can be an identifier taken as an ELF symbol name in the module
that contains a candidate PC address. I don't actually care what the
syntax is and I'll let Frank et al decide what's easy to parse and so
forth. This example syntax is to illustrate the exact semantics I have in
mind. (There may not be any need to support multiple ranges and such in
the syntax.) The subclause applies a filtering predicate to the list of PC
addresses chosen for probes by the existing clause like foo.function(...).
It probably makes sense to build in a similar predicate as a special case
applied to all kprobes, that gives a helpful diagnostic about any probe
requested in __kprobes_text_start .. __kprobes_text_end, which will not be
permitted by kprobes at stap module load time anyway.
I suspect the elfutils support to facilitate the translator doing the
symbol name translation is already adequate. I'll happily assist anyone
working on the translator to use it or improve it as necessary. Unless
there is already a similar item or someone sees a reason not to have a
translator feature aimed at your request, Anil, please file a bugzilla
enhancement item about this.
On Thu, Dec 08, 2005 at 07:24:14PM -0600, James Dickens wrote:
> well while its not what you want i used this
> global i
> probe module("nfs").function("*")
I am aware of the above wild start syntax, but I
am specifically looking at feature to insert probes
based on section name or based on the adress range.
If you see the way code is packed, supporting probes
based on section names or address range makes sense.