为什么Linux上的动态链接的可执行文件在其自己的内存空间中具有libc的完整内存空间？

Question

I compiled the following C code with gcc -Wall -m32 test.c -o test on a 64-bit Ubuntu system:

#include <stdio.h>
#include <stdlib.h>

int main() {
    char * buffer;
    buffer = (char*) malloc (1048576);
    printf("hi\n");
    sleep(20);
    return 0;
}

Now when I run the code and do a cat /proc/PID/maps to look at the virtual memory range the process is using I see the following:

08048000-08049000 r-xp 00000000 08:06 3805439  /home/me/test
08049000-0804a000 r--p 00000000 08:06 3805439  /home/me/test
0804a000-0804b000 rw-p 00001000 08:06 3805439  /home/me/test
f7475000-f7577000 rw-p 00000000 00:00 0
f7577000-f7720000 r-xp 00000000 08:06 8002662  /lib/i386-linux-gnu/libc-2.19.so
f7720000-f7721000 ---p 001a9000 08:06 8002662  /lib/i386-linux-gnu/libc-2.19.so
f7721000-f7723000 r--p 001a9000 08:06 8002662  /lib/i386-linux-gnu/libc-2.19.so
f7723000-f7724000 rw-p 001ab000 08:06 8002662  /lib/i386-linux-gnu/libc-2.19.so
f7724000-f7727000 rw-p 00000000 00:00 0
f7746000-f7748000 rw-p 00000000 00:00 0
f7748000-f7749000 r-xp 00000000 00:00 0        [vdso]
f7749000-f7769000 r-xp 00000000 08:06 8002671  /lib/i386-linux-gnu/ld-2.19.so
f7769000-f776a000 r--p 0001f000 08:06 8002671  /lib/i386-linux-gnu/ld-2.19.so
f776a000-f776b000 rw-p 00020000 08:06 8002671  /lib/i386-linux-gnu/ld-2.19.so
ffa60000-ffa81000 rw-p 00000000 00:00 0        [stack]

So the code area is between 08048000 and 0804b000, then there's the 1048576 Bytes on the heap for the buffer in f7475000-f7577000. But then between f7577000 and f7724000 there are roughly 1758972 Bytes for the dynamically linked libc (thats pretty much the size of the library on the HDD). Why is that? Same thing with ld a bit lower.

1. Why does the system map the whole libc and ld shared objects into the process' memory range? I thought there would only be a pointer to the libc which is loaded in memory only once systemwide?

2. Furthermore I definitely don't need the whole 1758972 Bytes in my memory. What's happening here?

3. Is /lib/i386-linux-gnu/libc-2.19.so in memory only once systemwide?

Answer 1

1. Why does the system map the whole libc and ld shared objects into the process' memory range? I thought there would only be a pointer to the libc which is loaded in memory only once systemwide?

It does map it once systemwide, then it maps those pages into each process' virtual memory address space. Those pages are shared by every process (at least the read-only parts)

You can't just have a "pointer" because pointers can only refer to things in the process' own address space, so if a library wasn't in that address space, how would you dereference the pointer? It would also mean the process needed to say "OK, I want this function, is that in my address space? No, but I have a pointer, so follow that" which would be much more complicated. Instead the OS and MMU hardware perform the indirections and mapping needed to make it appear as a single flat address space for every process.

2. Furthermore I definitely don't need the whole 1758972 Bytes in my memory. What's happening here?

Since every process using libc.so gets the same pages, it's much more efficient just to map the whole thing once and share it, rather than figure out which specific pages are needed by each process.

3. Is /lib/i386-linux-gnu/libc-2.19.so in memory only once systemwide?

Yes, because the same pages are mapped into each process.

This all applies to any ELF shared library, not just libc.so

Answer 2

You have to be able to access the elements in libc.so , so it has to be mapped into your memory. You can't access anything that isn't mapped.

As to whether its present once or multiple times, you'll have to explain exactly what you mean. I will be mapped into the address space of every process which uses it (which is pretty much every process). But only the parts which are actually used in each process will actually be loaded into main memory. And the text segment will be mapped directly from the .so file, without any backing store in the swap area. (I believe, at least. I've never actually looked at Linux, but this is the way most virtual memory work. It's why code in the library will usually have to be compiled with -fPIC .)

Answer 3

I thought there would only be a pointer to the libc which is loaded in memory only once systemwide?

What would such a pointer point to? A pointer can only point to something that is in your memory space.

It actually is in memory only once system-wide, though. Through the magic of memory management, it can appear in multiple process's memory, but actually be in memory only once.

Mapping only the parts of libc that you actually use seems theoretically possible, but probably not worth the complexity, since there would be no benefit on a 64-bit machine. It would involve significant additions to the mechanisms for handling shared libraries.