Bug 14689 - missing 'syscalls' tracepoints
Summary: missing 'syscalls' tracepoints
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
Depends on:
Blocks: 14690
  Show dependency treegraph
Reported: 2012-10-09 19:36 UTC by David Smith
Modified: 2018-10-18 17:33 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description David Smith 2012-10-09 19:36:27 UTC
Systemtap can only find less than half of the tracepoints perf knows about:

# perf list tracepoint | wc -l
# stap -l 'kernel.trace("*")' | wc -l

The majority of these missing tracepoints are the 'syscalls' family of tracepoints:

# perf list tracepoint | grep ' syscalls:' | wc -l
# perf list tracepoint | grep ' syscalls:' | head
  syscalls:sys_enter_socket                          [Tracepoint event]
  syscalls:sys_exit_socket                           [Tracepoint event]
  syscalls:sys_enter_socketpair                      [Tracepoint event]
  syscalls:sys_exit_socketpair                       [Tracepoint event]
  syscalls:sys_enter_bind                            [Tracepoint event]
  syscalls:sys_exit_bind                             [Tracepoint event]
  syscalls:sys_enter_listen                          [Tracepoint event]
  syscalls:sys_exit_listen                           [Tracepoint event]
  syscalls:sys_enter_accept4                         [Tracepoint event]
  syscalls:sys_exit_accept4                          [Tracepoint event]

Systemtap can't find those tracepoints:

# stap -l 'kernel.trace("sys_enter_")'
# stap -l 'kernel.trace("sys_exit_")'

These tracepoints only exist if CONFIG_FTRACE_SYSCALLS is enabled. If CONFIG_FTRACE_SYSCALLS is enabled, some macro magic automatically creates these tracepoints in the SYSCALL_DEFINEn macros.

(Note that this problem might be related to bug #10745)
Comment 1 Frank Ch. Eigler 2012-10-09 19:44:50 UTC
Note that stap does give access to the master tracepoints sys_enter and sys_exit.  At one point, the demultiplexing done by the kernel for perf/ftrace was such that there weren't really N low-level tracepoints that may be individually turned on/off.  If any was turned on, the process incurred a penalty for *every* syscall.  Demultiplexing was just a conditional postprocessing phase, by which time the damage was already done.  It roughly equivalent to

probe kernel.trace.sys_five = kernel.trace("sys_enter")
      { if ($syscall != 5) next; }

If this is still the case, then there is little point trying to connect to the same demultiplexing widget.

See also bug #12748.
Comment 2 Frank Ch. Eigler 2018-10-18 17:33:04 UTC
tp_syscalls.* present