Go to main content

Oracle® Solaris 11.4 DTrace (Dynamic Tracing) Guide

Exit Print View

Updated: September 2020
 
 

syscall Provider

The syscall provider makes available a probe at the entry to and return from every system call in the system. Because system calls are the primary interface between user-level applications and the operating system kernel, the syscall provider can offer tremendous insight into application behavior with respect to the system.

syscall Probes

syscall provides a pair of probes for each system call: an entry probe that fires before the system call is entered, and a return probe that fires after the system call has completed but before control has transferred back to user-level. For all syscall probes, the function name is set to be the name of the instrumented system call and the module name is undefined.

The names of the system calls as provided by the syscall provider may be found in the /etc/name_to_sysnum file. Often, the system call names provided by syscall correspond to names in Section 2 of the man pages. However, some probes provided by the syscall provider do not directly correspond to any documented system call. The common reasons for this discrepancy are described in this section.

System Call Anachronisms

In some cases, the name of the system call as provided by the syscall provider is actually a reflection of an ancient implementation detail. For example, for reasons dating back to the origins of UNIX, the name of exit in /etc/name_to_sysnum is rexit. Similarly, the name of time is gtime, and the name of execve is exece.

Subcoded System Calls

Some system calls as presented in man page section 2 are implemented as suboperations of an undocumented system call. For example, the system calls related to System V semaphores, such as semctl, semget, semids, semop, and semtimedop are implemented as suboperations of a single system call, semsys. The semsys system call takes as its first argument an implementation-specific subcode denoting the specific system call required: SEMCTL, SEMGET, SEMIDS, SEMOP, or SEMTIMEDOP, respectively. As a result of overloading a single system call to implement multiple system calls, there is only a single pair of syscall probes for System V semaphores:

syscall::semsys:entry and syscall::semsys:return

New System Calls

Oracle Solaris 11 implements the following system interfaces as individual system calls:

  • faccessat()
  • fchmodat()
  • fchownat()
  • fstatat()
  • linkat()
  • mkdirat()
  • mknodat()
  • openat()
  • readlinkat()
  • renameat()
  • symlinkat()
  • unlinkat()

These system calls implement a superset of the functionality of their old non-at-suffixed counterparts. They take an additional first argument that is either an open directory file descriptor, in which case the operation on a relative path name is taken relative to the specified directory, or is the reserved value AT_FDCWD, in which case the operation takes place relative to the current working directory.

Deleted System Calls

In Oracle Solaris 11, the following old system calls have been removed from the system. The libc interfaces remain, but they are reimplemented not as system calls in their own right, but as calls to the new system calls as indicated:

Removed System Call
Equivalent in Oracle Solaris 11
access(p, m)
faccessat(AT_FDCWD, p, m, 0)
chmod(p, m)
fchmodat(AT_FDCWD, p, m, 0)
chown(p, u, g)
fchownat(AT_FDCWD, p, u, g, 0)
creat(p, m)
openat(AT_FDCWD, p, O_WRONLY | O_CREAT |
                                                  O_TRUNC, m)
fchmod(fd, m)
fchmodat(fd, NULL, m, 0)
fchown(fd, u, g)
fchownat(fd, NULL, u, g, 0)
fstat(fd, s)
fstatat(fd, NULL, s, 0)
lchown(p, u, g)
fchownat(AT_FDCWD, p, u, g,
                                                  AT_SYMLINK_NOFOLLOW)
link(p1, p2) 
linkat(AT_FDCWD, p1, AT_FDCWD, p2, 0)
lstat(p, s)
fstatat(AT_FDCWD, p, s,
                                                  AT_SYMLINK_NOFOLLOW)
mkdir(p, m)
mkdirat(AT_FDCWD, p, m)
mknod(p, m. d)
mknodat(AT_FDCWD, p, m, d)
open(p, o, m)
openat(AT_FDCWD, p, o, m)
readlink(p, b, s)
readlinkat(AT_FDCWD, p, b, s)
rename(p1, p2)
renameat(AT_FDCWD, p1, AT_FDCWD, p2)
rmdir(p)
unlinkat(AT_FDCWD, p, AT_REMOVEDIR)
stat(p, s)
fstatat(AT_FDCWD, p, s, 0)
symlink(p1, p2)
symlinkat(p1, AT_FDCWD, p2)
unlink(p)
unlinkat(AT_FDCWD, p, 0)

Large File System Calls

A 32-bit program that supports large files that exceed two gigabytes in size must be able to process 64-bit file offsets. Because large files require use of large offsets, these files are manipulated through a parallel set of system interfaces. For more information, see the lf64(7) man page. These interfaces are documented in lf64, but they do not have individual man pages. Each of these large file system call interfaces appears as its own syscall probe as shown in the following table.

Table 56  syscall Large File Probes
Large File syscall Probe
System Call
fstatat64
fstatat
fstatvfs64
fstatvfs
getdents64
fgetdents
getrlimit64
getrlimit
mmap64
mmap
openat64
openat
pread64
pread
pwrite64
pwrite
setrlimit64
setrlimit
statvfs64
statvfs

Private System Calls

Some system calls are private implementation details of Oracle Solaris subsystems that span the user-kernel boundary. As such, these system calls do not have man pages in man page section 2. Examples of system calls in this category include the signotify system call, which is used as part of the implementation of POSIX.4 message queues, and the utssys system call, which is used to implement fuser. For more information, see the fuser(8) man page.

syscall Probe Arguments

For entry probes, the arguments arg0 .. argn are the arguments to the system call. For return probes, both arg0 and arg1 contain the return value. A non-zero value in the D variable errno indicates system call failure.

syscall Stability

The syscall provider uses stability mechanism of DTrace to describe its stabilities as shown in the following table. For more information about the stability mechanism, refer to DTrace Stability Mechanisms.

Table 57  Stability Mechanism for the syscall Provider
Element
Name Stability
Data Stability
Dependency Class
Provider
Evolving
Evolving
Common
Module
Private
Private
Unknown
Function
Unstable
Unstable
ISA
Name
Evolving
Evolving
Common
Arguments
Unstable
Unstable
ISA