Libc.so has four segments displayed in the process, why?

Question

To find out in which areas of the memory card the running program is located, I write a simple C program to read data from / proc / self / maps:

#include <stdio.h> #include <stdlib.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> int main() { char buf[1024]; int fd; ssize_t n; fd = open("/proc/self/maps", O_RDONLY); if (fd < 0) { perror(""); } while ((n = read(fd, buf, 1000)) > 0) { buf[n] = 0; printf("%s", buf); } close(fd); return 0; } 

The output of the program is as follows:

 1. 08048000-08049000 r-xp 00000000 08:01 2323014 /tmp/a.out 2. 08049000-0804a000 rw-p 00000000 08:01 2323014 /tmp/a.out 3. b7f69000-b7f6a000 rw-p b7f69000 00:00 0 4. b7f6a000-b80c6000 r-xp 00000000 08:01 1826975 /lib/tls/i686/cmov/libc-2.9.so 5. b80c6000-b80c7000 ---p 0015c000 08:01 1826975 /lib/tls/i686/cmov/libc-2.9.so 6. b80c7000-b80c9000 r--p 0015c000 08:01 1826975 /lib/tls/i686/cmov/libc-2.9.so 7. b80c9000-b80ca000 rw-p 0015e000 08:01 1826975 /lib/tls/i686/cmov/libc-2.9.so 8. b80ca000-b80cd000 rw-p b80ca000 00:00 0 9. b80dd000-b80df000 rw-p b80dd000 00:00 0 10.b80df000-b80e0000 r-xp b80df000 00:00 0 [vdso] 11.b80e0000-b80fc000 r-xp 00000000 08:01 1826830 /lib/ld-2.9.so 12.b80fc000-b80fd000 r--p 0001b000 08:01 1826830 /lib/ld-2.9.so 13.b80fd000-b80fe000 rw-p 0001c000 08:01 1826830 /lib/ld-2.9.so 14.bfee9000-bfefe000 rw-p bffeb000 00:00 0 [stack] 

As we can conclude from the execution bit and the recorded bit, the first two lines are connected with the code and program data segments, respectively.

But what confuses me is that libc.so has areas that are displayed from libc.so. One of them even has only a private bit; it cannot be written, read or executed. And one more interesting thing: ld.so has only three segments. Compared to libc.so segments, only the private bit is missing.

So, I would like to know what the four segments actually represent? I am using Ubuntu SMP with kernel 2.6.28, gcc 3.4.6 and binutils 2.19.

Answer 1

The r-xp , r--p and rw-p mappings are just regions that need different permissions.

Mystery mapping ---p is the result of virtual memory offsets of sections described in the ELF file that do not necessarily correspond to physical offsets in the file (there may be an addition for alignment).

i.e. The ELF file itself might look like this:

 | .... sections .... | .... more sections .... | 

... but we describe a memory layout that looks like this:

 | .... sections .... | gap | .... more sections .... | 

(You can see this with objdump -h or readelf -e .)

So, the general principle is that ld.so needs to allocate enough memory for everything:

 | | 

... then we make one mapping for the first part:

 | .... sections .... | | 

... and then do a second display to get the second part in the right place:

 | .... sections .... | | .... more sections .... | 

Then it protects the “hole” remaining in the virtual address space. This is the mysterious display you see:

 | .... sections .... |XXXXXXXXXXXXX| .... more sections .... | 

I believe that the hole is protected and not freed for reuse - so that everything is simple: this ensures that each library has only one range of virtual addresses that belongs to it and to no one else.