It is a pity that so much tracing clutter is produced by systems
employing shared libraries.
It is instructive to think about system call inputs and outputs
as data-flow across the user/kernel boundary. Because user-space
and kernel-space are separate and address-protected, it is
sometimes possible to make deductive inferences about process
behavior using inputs and outputs as propositions.
In some cases, a system call will differ from the documented
behavior or have a different name. For example, the faccessat(2)
system call does not have flags argument, and the setrlimit(2)
library function uses prlimit64(2) system call on modern
(2.6.38+) kernels. These discrepancies are normal but
idiosyncratic characteristics of the system call interface and
are accounted for by C library wrapper functions.
Some system calls have different names in different architectures
and personalities. In these cases, system call filtering and
printing uses the names that match corresponding __NR_* kernel
macros of the tracee's architecture and personality. There are
two exceptions from this general rule: arm_fadvise64_64(2) ARM
syscall and xtensa_fadvise64_64(2) Xtensa syscall are filtered
and printed as fadvise64_64(2).
On x32, syscalls that are intended to be used by 64-bit processes
and not x32 ones (for example, readv(2), that has syscall number
19 on x86_64, with its x32 counterpart has syscall number 515),
but called with __X32_SYSCALL_BIT flag being set, are designated
with #64 suffix.
On some platforms a process that is attached to with the -p
option may observe a spurious EINTR return from the current
system call that is not restartable. (Ideally, all system calls
should be restarted on strace attach, making the attach invisible
to the traced process, but a few system calls aren't. Arguably,
every instance of such behavior is a kernel bug.) This may have
an unpredictable effect on the process if the process takes no
action to restart the system call.
As strace executes the specified command directly and does not
employ a shell for that, scripts without shebang that usually run
just fine when invoked by shell fail to execute with ENOEXEC
error. It is advisable to manually supply a shell as a command
with the script as its argument.
