Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Since the majority of the Linux kernel is written in the C language, so when the kernel gets loaded in Main memory, does the standard C library also get loaded along the Linux kernel?
If that's the reason the programs written in C consume less memory than other program as the standard C library is already loaded and as a result are faster also (less page faults) compared to program written in other languages when run on a Linux machine?
The kernel is written in C, but it doesn’t use the C library (as dave_thompson_085 points out, it’s “freestanding”). Even if it did, a C library loaded along with the kernel for the kernel’s use would only be available to the kernel (unless the kernel made it explicitly accessible to user space, in some way or other), so it wouldn’t help reduce the memory requirements for programs.
That said, in most cases, the earliest programs run after the kernel starts (programs in the initramfs, although they’ll use their own copy of the C library; and ultimately, init), use the C library, so it ends up being mapped early on, and it’s highly likely that the portions of the library that are widely used will always remain in physical memory.
The kernel contains implementations of many of the C library’s functions, or variants (for example, printk instead of printf); but they don’t all follow the standard exactly. In some circumstances, the implementations of C library functions in the compiler are used instead.
(Note that the vast majority of programs written in languages other than C ultimately use the C library.)
Is the standard C library loaded by default in main memory in Linux?
No.
The first userspace process the kernel ever starts is called init, and its purpose is to start everything else, and to reap zombie children (processes whose parent processes exited before they did, so there is no other process to reap their exit status).
Because init almost always uses the standard C library, the standard C library is loaded in memory as soon as init starts. But that's just a side effect, and nothing the kernel cares about.
The kernel has nothing to do with the standard C library. (The kernel is written in freestanding C, an environment where the standard C library is not available.)
libc.so.6 on my system. So I assume it's long since inits started being dynamically-linked
"C standard library" in the kernel's context is more of an abstract form, meaning there is some reusable utility subroutine that does things as specified by the C language. Just like the reusable subroutines that is not defined by the C language but by kernel itself, these do not exist in a "shared object" (dynamic library) form. Instead, they are compiled together with the kernel and assemble into one kernel executable.
You can find some of the library code here, e.g. memcpy, strcmp/strncmp https://elixir.bootlin.com/linux/latest/source/arch/x86/lib
So kernel ships with its own C library implementation and doesn't share it with any other userland code, not does it use a C library that is provided by the user to boot. In fact, each userland program may do the same, e.g. static links (includes, packs) a C library and not share with anyone else.
To answer your last question, no userland program shares C standard library with the kernel.
No, the kernel doesn't use the standard C library.
Note that the standard C library (usually glibc is the one used with Linux) is "translating" C calls to kernel syscalls. Lots of things are completely done in userland, but it is built upon the kernel. So it wouldn't be that easy to use a C library that, in binary form, could be used both on the kernel as in userland. Also, the objective of their libraries are usually quite different.
And now, the second part. Each program loads the C library itself, even if pretty much every Linux program in the system is linking to the same standard C library.
You can call grep libc /proc/self/smaps a few times and see how libc is mapped on a different address each time (as a result of ASLR). This is in contrast to Windows, where a few libraries like kernel32.dll (the KnownDLL) are mapped on every process, at the same location, even if not explicitly loaded.
On Linux, the program (well, ld) will need to take the steps for loading libc just like every other dynamic library. Although it's true that the libc is one of the most optimized pieces of code, so that both its loading and general running is quick. Often, at a very low-level (have a look at Ulrich Drepper articles) that wouldn't be worth for normal programs.
If that's the reason the programs written in C consume less memory than other program
So no. The memory space will not consume less memory. The libc will still show the memory usage for the libc on the process.
as the standard C library is already loaded and as a result are faster also (less page faults)
It's true however that the code will already be loaded in memory, so it won't need to fetch it from disk (it is done per page, but the section of code your program needs was probably requested by a different one before).
In fact, Linux will aggressively cache the files in memory. If you have enough memory, once you load a program from disk, it will be cached in memory and it won't load again that code from the (slow) disk. Thus, you could achieve the same effect by loading them from disk in advance / having loaded them before.
compared to program written in other languages when run on a Linux machine?
It's unlikely that you might find them faster due to this small difference. More likely, I would think on the following reasons:
It's also possible that the other languages are not really that slower. You would need to specify a pair of such programs, in order to compare them equally, and then determine if really the C version if faster, and where the difference actually lies.
char * msg = "Hello world\n"; char buf[16]; strncpy(buf, msg, strlen(msg) + 1); printf("%s", buf); with and without optimisation to see what I mean. No C library optimisation can reduce that to movabsq $8031924123371070792, %rax followed by a printf call. That’s an artificial example, but similar patterns are common in real-world code, and they really are optimised like that (or using vector registers), by the C compiler.
Jun 4, 2020 at 8:49
The short name for the C standard library is libc.
Let's first make clear that libc is a library like any other.
The kernel itself does not use libc (as you can read here).
libc can be linked either dynamically or statically.
Dynamic linking:
The libraryis not embedded into the executable. When the program launches, the library is loaded from a system path. For example /lib/x86_64-linux-gnu/libc.so on linux.
And here it comes: If a second program launches libc is not loaded again. Instead it shares the library with the first program. This means no new memory is needed.
Static linking:
If libc was linked statically then the library is inside the executable. So if you run two programs libc is in memory twice.
.o). The linker will only include those object files that are needed to satisfy an undefined symbol. This is the core algorithm of ld, nothing to do with DCE (which is a compilation pass to eliminate parts of your own code that aren't used, long before the linker runs). Of course, if there are multiple routines in a single object file, some of them may be included unnecessarily (that can be avoided by using the non-default one-section-per-function layout).
.a file is just a bunch of .o files packed together. You can browse it with various general-purpose archiving tools, unpack/modify it using ar, etc.. Unless you supply the --whole-archive option to the linker, it will only use the .o's that are necessary. See a description of that option in man ld for details.
Linux (and later versions of Unix) support shared libraries. This is the big difference. A shared library is loaded in memory and is read only. If another program loads the same resource it simply gets a link to the existing in memory resource. This is why shared memory (.so) are fast, low memory usage and why static linked (think .a) programs are bigger in all ways. There are advantages to .a, but memory usage and program startup speed aren't among them. Not that this only applies to the code, not variables which are all in the user space. As for the standard library, chances are one of the early to load programs will use libc.so and almost every other program as well. That means it is in memory and only one copy of the code is needed.
