trace -- system call tracer


trace [-b format] [-n] [-c] [-S] [-d stackDepth] [-p processId] [-o outputFile]
[-t] [-e entryName] [-f (both | child | parent)] program [arguments]


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.

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.

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.

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.

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.


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.
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003