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: How to express in systemtap?


> I am trying to insert probes on all functions belonging to a particular
> section.

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

> 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:

	probe kernel.function("*").pc(__sched_text_start .. __sched_text_end)

That is, an optional subclause on probe types that yield PC addresses for
probe locations:

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


Thanks,
Roland


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