1

By system calls, I mean functions like man 2 brk, not the 0x80 interrupt.

If I understand this thread correctly, a compiled C program never DIRECTLY invokes system calls. It can only invoke library calls, which might be dynamically linked from glibc.

However, man 3 brk returns No manual entry for brk in section 3. So I guess one of the following has to happen for the brk to be executed properly:

  1. My understanding above is wrong. Programs can invoke system calls without glibc support. But how is brk linked into the program then?
  2. There is indeed a glibc wrapper for the system call brk. Then which brk is included when I #include <unistd.h>? The glibc one or the system call one? If it is the glibc one, why is it not documented in man 3? Where can I find a complete list of available library calls?
3

For most of the system calls with man pages in section 2, the man pages actually describe the C library wrappers. The exceptions are usually mentioned explicitly, like gettid that @Sergei Kurenkov refer's to in their answer:

NOTES Glibc does not provide a wrapper for this system call; call it using syscall(2).

Similarly with pivot_root (which isn't that useful for general applications), tgkill (which performs the low-level function of pthread_kill). Then there's readdir, where the actual system call is somewhat different from the library function:

DESCRIPTION This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface, which is superseded by getdents(2).

Note that there has to be some sort of wrapper. Function calls are made using the C calling conventions, which is different from the calling convention of the kernel interface. Usual function calls are made with the call assembly instruction (or similar), kernel calls with syscall or int 0x80 (and that's not counting stuff like gettimeofday or getpid in the vdso). The compiler doesn't (need to) know which function calls map to an an actual kernel call.

Even with the "usual" system calls, the C library wrapper acts slightly differently from the bare system call: The system calls return the error codes as varying negative values (if you look at the Linux kernel code, you'll see a lot of returns like return -EPERM;). The C library wrapper turns all such return values to -1, and moves the actual error code to errno.

2

a compiled C program never DIRECTLY invokes system calls.

it is not true. Take a gettid as an example: http://man7.org/linux/man-pages/man2/gettid.2.html. It does not have a wrapper so you need in your program write something like (from man: Glibc does not provide a wrapper for this system call; call it using syscall(2).):

#ifndef WIN32

#include <linux/unistd.h>
#include <sys/syscall.h>
#include <unistd.h>
int thread_gettid(void) {
    return static_cast<int>(syscall(SYS_gettid));
}
#else
int thread_gettid(void) {
    return GetCurrentThreadId();
}
#endif

My understanding above is wrong. Programs can invoke system calls without glibc support.

Indeed, it can. It uses syscall: http://man7.org/linux/man-pages/man2/syscall.2.html.

But how is brk linked into the program then?

Seems like brk has got indeed a wrapper in glibc, since there is this line in the man:

The return value described above for brk() is the behavior provided 
by the glibc wrapper function for the Linux brk() system call.

If it is the glibc one, why is it not documented in man 3

I think it is because there is malloc for memory allocations that has to be used:

Avoid using brk() and sbrk(): the malloc(3) memory allocation package is the portable and comfortable way of allocating memory.

  • Though it might not be hard to argue that even using syscall does involve glibc support, even the manual page says that "syscall() is a small library function that invokes the system call whose assembly language interface has the specified number ..." – ilkkachu Jun 15 '17 at 11:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.