trace(CP)
trace --
system call tracer
Syntax
trace [-b format] [-n] [-c] [-S]
[-d stackDepth] [-p processId]
[-o outputFile]
[-t] [-e entryName]
[-f (both | child | parent)]
program [arguments]
Description
The
trace(CP)
command prints the names and arguments to the system calls executed by
program.
The program being traced,
program,
must not be stripped, because
trace
uses the symbol table to place breakpoints at the entry points of system
routines.
trace
prints the name and arguments of system calls after the call
returns.
This behavior may be changed with the
-n
flag
to print the name and arguments before the system call.
This can be useful when system calls hang or execute
for a long time (for example,
read(S)
or
wait(S)).
By default, trace scans program to determine
its file format and executes the appropriate binary.
Use the option -b format
to force prof to use a particular file format.
-b format-
Do not scan program.
Use format
as the file format of program.
format can be
any one of elf, coff and ibcs2.
ibcs2 is equivalent to coff.
The case of format is not significant.
-c-
Print the name of the routine that called the system call.
If the program is compiled with the -g debugging flag,
also print the line number within the source file
from which the call was made
(see also the -d flag).
-d stackDepth-
Control the depth of the stack traceback for the
-c flag.
trace prints stackDepth
entries in the call chain.
The default value is 1.
-e entryName-
Trace only the system call
entryName.
This option may be repeated to specify several system call
names.
Programs being traced execute slowly each time that a system call is
invoked. Use the -e
flag to trace only selected system calls, in order to speed up the tracing.
-f both | child | parent-
Control the handling of child processes.
If both
is specified, child processes are traced as well.
Each line of output is prefixed with the process ID (PID) of
the process that made the system call.
If child
is specified, after a
fork(S)
the parent is released and
the child is traced.
Each line of output is prefixed with the PID of
the process that made the system call.
If parent
is specified, children are released to run normally.
-n-
Print the name of the system call before the
system call is invoked.
This allows detection of long system calls, such as
wait( ).
-o outputFile-
Print all the trace information to file
outputFile.
The default value is standard output.
-p processId-
On systems that support
ptrace(S)
of arbitrary processes, the
-p
flag allows tracing of an already executing process.
An interrupt causes the process to be detached
to continue running normally.
SCO UNIX system 3.2v4 and later support this feature.
-S-
Pass keyboard signals to traced process.
Normally,
trace
intercepts SIGINT and SIGQUIT,
and terminates,
killing or releasing traced process(es).
If
-S
is selected,
trace
ignores these signals, allowing them
to be passed to the traced process(es).
Note that this can make
trace
hard to stop.
If
trace catches SIGINT
or SIGQUIT,
and trace was not invoked with the
-p
option, all traced processes are terminated.
If trace
was invoked with the
-p
option, traced processes are released.
-t-
Do not require a symbol table.
Normally,
trace
requires a symbol table in the target program.
If the program was linked with a shared library, some of the
system calls will be in the shared library, and can be traced
even if the binary has been stripped.
However, not all the system calls will be reported, and so the
output can be misleading when this option is used.
trace
searches your $PATH to find the executable file.
Thus, if ``.'' is not in your $PATH, you must use
./program to trace a program in your current directory.
Warning
Trace ignores SIGINT and SIGQUIT
so that only the program gets them.
This can sometimes make trace hard to stop.
If the traced process blocks a SIGTRAP signal,
the traced process may
fail with a segmentation violation, or it may hang.
On SCO UNIX system 3.2v4.2 and earlier,
sleep(S)
blocks SIGTRAP.
If a traced system call is interrupted by a signal, the signal
is caught, and the signal handler longjumps to the same code
address to which the system call would have returned, then
trace
may report the wrong value for the return value of the system
call.
If you try to trace a non-executable COFF file (for example, a
.o file), trace reports a permission error.
This is because
execvp(S)
intercepts the failure to
exec(S)
the file and then attempts to exec
/bin/sh to run it as a script.
Since /bin/sh is not normally readable, you cannot
exec(S)
it traced.
See also
exec(S),
fork(S),
signal(S),
sleep(S),
strip(CP),
ptrace(S)
Standards conformance
trace(CP)
is not part of any currently supported standard;
it is an extension of AT&T System V
developed by The Santa Cruz Operation, Inc.
and maintained by The SCO Group.
© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 02 June 2005