Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Solaris Dynamic Tracing Guide
Previous Next

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 UNIXTM antiquity, the name of exit(2) in /etc/name_to_sysnum is rexit. Similarly, the name of time(2) is gtime, and the name of both execle(2) and execve(2) is exece.

Subcoded System Calls

Some system calls as presented in Section 2 are implemented as suboperations of an undocumented system call. For example, the system calls related to System V semaphores (semctl(2), semget(2), semids(2), semop(2), and semtimedop(2)) 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.

Large File System Calls

A 32-bit program that supports large files that exceed four gigabytes in size must be able to process 64–bit file offsets. Because large files require use of large offsets, large files are manipulated through a parallel set of system interfaces, as described in lf64(5). 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 Table 21-1.

Table 21-1 sycall Large File Probes

Large File syscall Probe

System Call

creat64

creat(2)

fstat64

fstat(2)

fstatvfs64

fstatvfs(2)

getdents64

getdents(2)

getrlimit64

getrlimit(2)

lstat64

lstat(2)

mmap64

mmap(2)

open64

open(2)

pread64

pread(2)

pwrite64

pwrite(2)

setrlimit64

setrlimit(2)

stat64

stat(2)

statvfs64

statvfs(2)

Private System Calls

Some system calls are private implementation details of Solaris subsystems that span the user-kernel boundary. As such, these system calls do not have man pages in 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(1M).

Previous Next

 
 
  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire