pre-processing of probe points

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

pre-processing of probe points

Guang Lei Li
Hi,

  I am now writing some tapsets for syscalls, io etc. But I found
different architectures differs in probe point definitions.

  For example, in order to trace all syscalls in ppc64(for both 32-bit and
64-bit application), you should probe the following function entries:
    sys_*, sys32_*, compat_sys_*, ppc_fork, ppc32_lseek, ...(defined in
sys_call_table/sys_call_table32 in arch/ppc64/kernel/misc.S)

  While on i386, it's enough to probe only sys_* for all syscalls

  One solution is to write different tapsets which holds the probe points
definitions for different architectures. But I think it may be better if
we can do some pre-processing during the parse stage of systemtap.

  I found from the manpage of stap(1) that currently systemTap has already
a simple conditional preprocessing:
      %( CONDITION %? TRUE-TOKENS %)
      %( CONDITION %? TRUE-TOKENS %: FALSE-TOKENS %)
  But here the CONDITION could only be kernel_vr or kernel_v.

  So it's appropriate to add more supports(arch=xxx) to CONDITION, or add
some other preprocessing mechanism so that the probe points can be well
adaptive to different situations?

Best Regards,

Li Guanglei

- Linux Performance, China Systems & Technology Lab
China Development Labs, Beijing Tel: 86-10-82782244 Ext.3516  Email:
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: pre-processing of probe points

Frank Ch. Eigler

Guang Lei Li <[hidden email]> writes:

> I am now writing some tapsets for syscalls, io etc.

Please also see Kevin's tapset/system_calls.stp.

> But I found different architectures differs in probe point
> definitions. [...]  So it's appropriate to add more
> supports(arch=xxx) to CONDITION [...]

Yes: bug #1903.

- FChE