HP-UX Reference (11i v2 07/12) - 2 System Calls (vol 5)

t
ttrace(2) ttrace(2)
in the context of the process, all threads in the process respond to the event. When set in the context of a
thread, only the specific thread will respond to the event.
Important
If an event is requested by the process, the event mask of the thread is not examined. For the event mask
of the thread to be significant, the process event must be be unset. Similarly, if an event option is enabled
in the process, the option for the thread is not considered. Event masks may be inherited across
fork()
using the tte_opts options in the ttevent_t
structure. If TTEO_PROC_INHERIT
is set, the child
process inherits the event mask of its parent. If
TTEO_LWP_INHERIT
is set, the lwp inherits the event
mask of the lwp that invoked
fork(). If the latter is set, the lwp created by
lwp_create() also inher-
its the event mask of the creating thread.
These events are:
TTEVT_SIGNAL This event flag indicates that the traced thread needs to examine signal mask bits when
processing signals. This means that, by default, threads stop when receiving a signal. If
the signal being processed has its mask bit set, signal processing continues as though
the process were not traced: the traced thread is not stopped, and the tracing process is
not notified of the signal. On the other hand, if the signal mask bit is not set for the sig-
nal being processed, the traced thread is stopped and the tracing process is notified via
ttrace_wait() .
Note that the SIGKILL signal can never be unmasked. It behaves as though its mask
bit were always set. This means that a SIGKILL signal cannot be used to stop a traced
thread. The SIGTRAP signal is also special in that it is used to stop traced threads
when they respond to a trap, such as a breakpoint or a single step. Consequently,
masking SIGTRAP, even though allowed, will result in unexpected behavior in these
conditions.
TTEVT_FORK This event flag indicates that the traced thread needs to take special action when it
invokes fork(). When set, both the parent thread and the initial thread in the child
process stop (after the child process is marked as a traced process and adopts its
parent’s debugger). Both threads log the fact that they stopped in response to a
TTEVT_FORK event. The parent thread provides the pid of the child process in the
appropriate portion of the ttstate_t structure. The initial thread of the child pro-
cess provides the pid of the parent in the same location. See the ttstate_t structure
description for further details.
TTEVT_VFORK This event flag indicates that the traced thread needs to take special action when it
invokes
vfork(). The behavior is identical to that of TTEVT_FORK but it is impor-
tant to note that the caveats with respect to vfork(), continue to apply here. In par-
ticular, it needs to be remembered that when the child process stops, its parent is
asleep, and that the child borrows the parent’s address space until a call to exec() or
an exit (either by a call to
exit() or abnormally) takes place. Continuing the parent
process before the above steps take place results in an error.
TTEVT_PREFORK
This event flag indicates that the traced thread needs to notify the debugger, during a
fork() or vfork() operation, just after the child process ID and thread ID is known
and before the child process is created and set to run. The parent thread is stopped and
it provides the pid of the child process and lwpid of the child’s initial thread.
Note: Upon continuation from this event, the traced thread does not guarantee that the
child process with an earlier returned pid and lwpid can be created since the fork()
or vfork() operation might fail.
TTEVT_FORK_FAIL
This event flag indicates that the traced thread needs to notify the debugger upon the
failure of a fork() or vfork() operation. The traced parent thread is stopped and
returns the error code for fork failure.
TTEVT_EXEC This event flag indicates that a traced thread needs to notify the debugger upon comple-
tion of loading the new executable file, in the exec() system call. The length of the
pathname string (not including a null terminating character) is returned in the
ttstate_t structure. The path may subsequently be obtained using the
TT_PROC_GET_PATHNAME request.
490 Hewlett-Packard Company − 10 − HP-UX 11i Version 2: December 2007 Update