libc.so有一个过程映射四个段，为什么呢？

Question

要看到的存储器映射的区域运行的程序包含，我编写一个简单的C程序，以读出的数据从/ proc /自/映射：

#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;
}

程序看起来像这样的输出（标记的）：

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]

我们可以从执行位和可写的位推断，前两行分别与该程序的代码和数据段相关联。

但什么让我困惑的是，libc.so的，也有被从libc.so.映射区域其中一人甚至只设有私人位，它不能写，读，或执行。 而另一有意思的是，ld.so只有三段。比较libc.so的段时，一个与上只有私人位被缺失。

所以我想知道什么是四段实际上呢？我使用Ubuntu SMP内核2.6.28，GCC 3.4.6和binutil 2.19。

Answer 1

在r-xp，r--p和rw-p映射是简单地需要不同的权限的区域。

在神秘---p映射是由未必匹配文件内的物理偏移的ELF文件中描述的部分的虚拟存储器偏移量的结果（可能有用于对准的原因填充）。

即。 ELF文件本身可能是这样的：

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

...但描述的存储器布局，看起来像这样：

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

（你可以看到这一点使用objdump -h或readelf -e。）

因此，一般的原则是，ld.so需要的一切分配足够的内存：

|                                                            |

...然后使所述第一部分的一对一映射：

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

...然后使第二映射来获得在正确的位置的第二部分：

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

然后，它保护了在虚拟地址空间留下的“洞”。这是神秘映射，你看到：

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

相信孔被保护 - 而不是释放以供重新使用 - 为了保持简单：它确保每个库仅具有单个虚拟地址范围，属于它和没有其他人