问题
I am looking to write a program that will need to do low level work with processes (ie. using the fork system call, among others). This program is to be written in C++ and is to run only on Linux. Ideally, it will be portable across CPU architectures (ie. x86, x86_64, and arm) with nothing more than a recompile, but I only really need x86_64 support.
As each Linux system call takes a number of arguments and returns a number of arguments in cpu registers (often only 1 return value), then a C function wrapper for each system call is likely easy to make. Also, because, AFAIK, system calls, being implemented in the kernel, have identical arguments and return values, if different assembly-level implementations, the same C interface can be exposed.
Does such a thing exist? If so, how can I access it?
Where is its documentation (list of available functions, their arguments with an explanation, and an explanation of exactly what the function does)?
回答1:
libc already includes the wrapper functions you're looking for. The prototypes for many of them are in #include <unistd.h>, as specified by POSIX.
C is the language of low-level systems program on Unix (and Linux), so this has been a thing since Unix existed. (Providing wrapper functions in libc is easier than teaching compilers the difference between function call and system calls, and allows for setting errno on errors. It also allows for tricks like LD_PRELOAD to intercept system calls in user-space.)
The man pages for system calls are in section 2, vs. section 3 for library functions (which might or might not use system calls as part of their implementation: math.h cos(3), ISO C stdio printf(3) and fwrite(3), vs. POSIX write(2)).
execve(2) is the system call.
See execl(3) and friends are also part of libc, and eventually call execve(2). They are convenience wrappers on top of it for constructing the argv array, doing $PATH lookup, and passing along the current process's environment. Thus they're classed as functions, not system calls.
See syscalls(2) for an overview, and complete list of system Linux calls with links to their man-page wrappers. (I've linked the Linux man pages, but there are also POSIX man pages for all of the standard system calls.)
In the unlikely case that you're not linking libc, you can use macros like MUSL's syscall2 / syscall3 / etc. macros (the number is the arg count) to inline the right asm on whatever platform. You use __NR_write from asm/unistd.h to get system call numbers.
But note that the raw Linux system calls might have small differences from the interface provided by the libc wrappers. For example, they won't check for pthreads cancellation points, and brk / sbrk requires bookkeeping in user-space by libc.
See SYSCALL_INLINE in Android for a portable raw sys_write() inline wrapper using MUSL macros.
But if you are using libc like a normal person for functions like malloc and printf, you should just use its system call wrapper functions.
回答2:
The syscalls(2) man page lists every system call available on Linux (and gives a link to the documentation of each of them). Most of them have their C wrapper in libc (for example, write(2), fork(2) etc etc...). A typical system call wrapper manages the calling conventions (see x86 ABI specifications here) and sets errno(3) on failure. ALP is a good but old introduction to Linux system programming, but you might find something newer (and ALP don't mention recent system calls like signalfd(2) because when ALP was written, these system calls did not exist).
Most C standard library implementations (e.g. your libc.so) on Linux provide the POSIX interface to system calls. And they usually are free software (e.g. GNU glibc or musl-libc and others). So if you care about gory implementation details (you usually shouldn't), study (or improve) their source code.
Very few system calls are not interfaced by the libc, because they are unusual and don't make much sense in C code. For example, sigreturn(2), socketcall(2), gettid(2) (or renameat2(2); you'll use renameat instead). If you really need to use these directly (which is improbable and likely to be a design bug in your program) you need to code some assembler code (specific to your system and instruction set architecture) or perhaps use syscall(2).
Some system calls evolved with time or appeared in later kernels but did not exit ten years ago. The system call numbers (as understood by the kernel) might be listed in some asm/unistd_64.h file (which you probably don't want to include, prefer sys/syscalls.h instead). For example, the preadv(2) syscall is redirected to either __NR_preadv or __NR_preadv2 but your libc should be clever enough to do the best it can.
Some new system calls did not exist in old kernels. A recent libc might in that case "emulate" them otherwise. But you should trust your libc implementation (and your kernel) most of the time. In practice, libc.so is the cornerstone of your Linux system and distribution (and you'll better use it as shared library and avoid statically linking it because of nsswitch.conf(5)). If you need to understand in details how shared libraries work, read Drepper's How to Write Shared Libraries. If you want some gory details about the system call mechanism in userland, see perhaps Assembler HowTo.
In almost all cases, you write somehow portable C code and use only the functions documented in syscalls(2) (as having a C wrapper) and intro(2).
In practice your shell-like program would use fork(2), execve(2), waitpid(2) etc. All these are specified by POSIX and available (and wrapped) in libc. You could study the source code of some free software shell for inspiration.
For the purpose of C programming on Linux, consider as system call any functions listed in syscalls(2) and having a C wrapper (e.g. almost all of them). So socket(2) or bind(2) is also in practice a system call (even if both internally use socketcall(2), which you won't call directly) Notice that system(3) -a very poorly named function for historical reasons- is not a system call. It is implemented above fork(2), execve(2), signal(2), waitpid(2) etc... and requires /bin/sh ...
来源：https://stackoverflow.com/questions/51120807/how-can-i-make-linux-system-calls-from-a-c-c-application-without-using-assemb