This is the mail archive of the
mailing list for the systemtap project.
Re: Tapset for Signals....
- From: Li Guanglei <guanglei at cn dot ibm dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: Manoj S Pattabhiraman <mpattabh at in dot ibm dot com>, systemtap at sourceware dot org
- Date: Wed, 16 Aug 2006 16:36:05 +0800
- Subject: Re: Tapset for Signals....
- Organization: IBM CSTL
- References: <C56DB814FAA30B418C75310AC4BB279D62E613@scsmsx413.amr.corp.intel.com>
Below are my questions while I am trying to add signal trace hooks
Stone, Joshua I wrote:
* signal.send: I did a lot of digging for this to try to capture all of
the paths where signals can be sent. The attached "send_signal.pdf"
shows the callgraph as I found it. Those 4 marked in blue are the
points that I chose to probe for "process.send_signal". The advantage
to probing them separately is that I can expose a 'shared' variable that
indicates whether the signal is going to a specific thread or the entire
thread group. The functions marked in red are those that can generate
STOP/KILL signals, which I haven't found a convenient way to probe
(perhaps static markers?).
1. group_send_sig_info() will check the permissions for sending the
signal before calling __group_send_sig_info(). So probing
__group_send_sig_info() will omit the situation that a signal has been
actually sent out but was rejected due to wrong permission.
But __group_send_sig_info() will be also called by the following
functions besides group_send_sig_info(),:
1> do_notify_parent() when a process exits
2> check_process_timers() for POSIX timers
So which one do you prefer to probe, __group_send_sig_info or
2. send_sigqueue() and send_group_sigqueue() is only used for POSIX
timers. If we choose to probe them, then I think it's better to add a
local variable like "send_to_queue=1" to indicate that the signal is
generated by posix timers. Then by looking at "send_to_queue" and
"shared" local variables, we can determine which function actually
triggers the probe handler.
* handle_stop_signal: Your comment says "fires when a stop signal is
sent", but this is incorrect. This function is called to _check_
whether this signal is a stop/cont, and if so take special action.
Thus, this will get called for almost every signal, many of which will
not be stop signals.
Yes. You are right. But the comment is still unchanged. :-)
* syscall duplication: some of your probes are duplicating points from
the syscall tapset (signal.syskill, etc.). Do we really need these? If
you really want these, it would be preferable to make use of the syscall
probe signal.syskill = syscall.kill