libc.so tiene cuatro segmentos asignados en un proceso, ¿por qué?

Question

Para ver qué regiones de mapa de memoria contiene un programa en ejecución, que escribir un programa simple C para leer datos desde / 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;
}

La salida del programa es similar al siguiente (marcado):

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]

Como podemos inferir del bit de ejecución y el bit de escritura, las dos primeras líneas están asociados con el código y de datos segmentos del programa, respectivamente.

Pero lo que me confunde es la de libc.so, existen para las regiones que se asignan a partir libc.so. Uno de ellos incluso sólo ha poco privada, que no se puede escribir, leer, o ejecutados. Y otra cosa interesante es que ld.so sólo tiene tres segmentos. En comparación con los segmentos de libc.so, el de bits sólo en privado no se encuentra.

Así que me gustaría saber cuáles son los cuatro segmentos hacen realidad? Estoy usando Ubuntu SMP con el kernel 2.6.28, gcc 3.4.6 y binutils 2.19.

Answer 1

El r-xp, r--p y rw-p asignaciones son simplemente regiones que necesitan diferentes permisos.

El mapeo misterio ---p es una consecuencia de las compensaciones de memoria virtual de secciones descritas por el archivo ELF no necesariamente búsqueda de los desplazamientos físicos dentro del archivo (puede haber relleno por razones de alineación).

es decir. el archivo ELF en sí podría tener este aspecto:

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

... pero describe un diseño de memoria que es similar al siguiente:

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

(Usted puede ver esto utilizando objdump -h o readelf -e.)

Por lo tanto, el principio general es que las necesidades ld.so asignar suficiente memoria para todo:

|                                                            |

... a continuación, hacer una asignación para la primera parte:

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

y

... luego hacer una segunda asignación para obtener la segunda parte en el lugar correcto:

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

A continuación, protege el "hueco" que se deja en el espacio de direcciones virtuales. Este es el mapeo de misterio que ves:

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

Creo que el agujero está protegido - en lugar de liberado para su reutilización - con el fin de mantiene las cosas simples: se asegura de que cada biblioteca tiene un único rango de direcciones virtuales, que pertenece a la misma y nadie más