How do the standard C library and system calls work together?

Question

I recently got interested about inner workings of compilers, standard libraries and kernels. While I was searching for the source code of the standard C library, I came across with Glibc. But what it says in Glibc's official website is: the library which defines the ''system calls'' and other basic facilities such as open, malloc, printf, exit...

So I guess that Glibc actually doesn't provide the source code of the standard C library, but instead provides the system calls for those functions, and then the kernel takes care of them, am I right?

I would like to learn more about those things. For example, how do the sin , printf , and strlen , functions get executed in C programs? If Glibc provides just the system calls, where are the actual source codes of those functions? How does the kernel execute them? Where can be found the source code of the part of the kernel that executes those functions?

Answer 1

The C library is a userland library almost like any library.

The System Calls are an interface provided by the kernel. They have nothing to do with the C standard. They are OS specific. Some similarities exist between UNIX-like operating systems but that's a different topic.

Some of the functions implemented in the C library will end-up calling a system call one way or another. But that's just the same with any other library.

I recommend looking at the C library from OpenBSD. Android phones use it as well. It's simple and clear and very well documented. You can find it here .

Answer 2

Glibc provides the code for library functions, and also provides syscall definitions. Only small part of provided functions are really syscalls. Others have its code inside library and either do all its work internally, or delegate it to kernel by calling it internally. You can see inside varous libc sources to get how they work. Source for Glibc, Eglibc, Newlib, Dietlibc and so on are for you.

Though it is possible to have OS that have system call for any libc call it is not done for many reasons.

Answer 3

You can get a feeling for the system calls at this page . It's old, but gives you the idea and a pointer to files in the kernel where the calls are implemented. There are low hundreds of system calls in a typical unix system. For example you can see sys_open, or sys_write. When you look at calls like fopen or open, at the end of the day they all map down to sys_open. Things like printf or write map down to sys_write.

The kernel mediates things like access to files, so needs to be a choke point, but the library makes it easier to access these calls by wrapping them in helpful abstractions, often more than one for a given system calls. The libraray doesn't provide the system calls themselves, it sets things up and then traps to the kernel, which implements them. The system calls are effectively the API of the kernel that libc programs against.

Some calls, like strlen, don't need kernel access at all, that call can just look at memory that's already been allocated.

A good tool for exploring this from user space is strace . Given a program it will show all the system calls the program makes. You can use this to tease out how libc calls map to system calls.