Question

To see what memory map regions a running program contains, 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 looks like this (labeled):

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 infer from the execution bit and writable bit, the first two lines are associated with the code and data segments of the program respectively.

But what confuses me is that of libc.so, there are for regions which are mapped from libc.so. One of them even only has private bit, it cannot be written, read, or executed.
And another interesting thing is that ld.so has only three segments. Comparing to libc.so’s segments, the one with only private bit on is missing.

So I’d like to know what are the four segments do actually? I’m 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 simply regions that need different permissions.

The mystery ---p mapping is a consequence of virtual memory offsets of sections described by the ELF file not necessarily matching the physical offsets within the file (there may be padding for alignment reasons).

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

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

…but describe a memory layout that looks like this:

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

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

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

|                                                            |

…then make one mapping for the first part:

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

…and then make a second mapping to get the second part in the right place:

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

It then protects the “hole” that is left in virtual address space. This is the mystery mapping that you see:

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

I believe the hole is protected – rather than freed for re-use – in order to keeps things simple: it ensures that each library has only a single virtual address range, which belongs to it and no-one else.