libc.so a quatre segments mis en correspondance dans un processus, pourquoi?

Question

Pour voir quelles régions carte mémoire d'un programme en cours contient, j'écrire un programme simple C pour lire les données / proc / auto / cartes:

#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 sortie du programme ressemble à ceci (étiqueté):

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]

Comme on peut le déduire à partir du bit d'exécution et le bit inscriptible, les deux premières lignes sont associées aux segments de code et de données du programme, respectivement.

Mais ce qui me confond est celle de libc.so, il y a des régions qui sont mis en correspondance à partir libc.so. L'un d'eux a même que peu privé, il ne peut pas être écrit, lu, ou exécuté. Et une autre chose intéressante est que ld.so a seulement trois segments. En comparaison avec les segments de libc.so, celui avec seulement peu privé manque.

Je voudrais savoir quels sont les quatre segments en réalité? J'utilise Ubuntu SMP avec le noyau 2.6.28, 3.4.6 gcc et binutils 2.19.

Answer 1

Le r-xp, les correspondances de r--p et rw-p sont simplement des régions qui ont besoin d'autorisations différentes.

Le mappage mystère ---p est une conséquence des décalages de mémoire virtuelle de sections décrites par le fichier ELF correspondant pas nécessairement les décalages physiques dans le fichier (il peut y avoir un rembourrage pour des raisons d'alignement).

i.e.. le fichier ELF lui-même pourrait ressembler à ceci:

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

... mais décrire une mise en page de mémoire qui ressemble à ceci:

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

(Vous pouvez le voir en utilisant objdump -h ou readelf -e.)

Ainsi, le principe général est que ld.so doit allouer suffisamment de mémoire pour tout:

|                                                            |

... puis faire une cartographie pour la première partie:

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

... et puis faire une deuxième application pour obtenir la deuxième partie au bon endroit:

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

Il protège alors le « trou » qui reste dans l'espace d'adressage virtuel. Ceci est la mise en correspondance de mystère que vous voyez:

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

Je crois que le trou est protégé - plutôt que libéré pour une réutilisation - pour garde les choses simples: il assure que chaque bibliothèque ne dispose que d'une seule plage d'adresses virtuelle, qui lui appartient et personne d'autre