Pourquoi les programmes de chargement des programmes d'assemblage ( Je suppose que le système d'exploitation peut alors déplacer les segments autour ou une optimisation de la mémoire pour le type de données stockées. Les pensées? .Data / .bss et .text ) dans des blocs de mémoire distincts au lieu de charger les données et les segments de code dans un seul bloc de mémoire?
3 Réponses :
Vous pouvez normalement définir des attributs sur une base de segment par secteur. Par exemple, un segment en lecture seule vous permet de spécifier une fois "en lecture seule" une fois et simplement mettre des données en lecture seule dans ce segment, plutôt que de spécifier la lecture seule sur une base variable par variable.
Ce n'est pas limité aux programmes de montage, c'est la manière dont le format exécutable de votre système d'exploitation est défini et la plupart des systèmes d'exploitation ont décidé d'avoir un format assez étendu pour les exécutables, séparant diverses parties d'un programme en sections ("segments") .
Séparation d'un exécutable dans différentes sections présente plusieurs avantages, par exemple. ceux que vous mentionnez:
.bss: stocke des informations sur la mémoire qui doit être mise à zéro au démarrage du programme. La mémoire à zéro est courante et un système d'exploitation a typiquement des services spéciaux pour la remise de la mémoire à zéro et si vous allouez allouer une matrice globale de 1 Mo, vous n'avez pas besoin d'intégrer 1 Mo de 0 dans l'exécutable - vous pouvez Il suffit de coder cette information dans la section .bss et le système d'exploitation allouera 1 Mo au démarrage du programme.
.Data: Toutes vos données sont initialisées à autre chose que zéro au démarrage du programme.
.text: C'est le code réel
Il y a peut-être beaucoup plus de sections, par ex. Sections spéciales contenant du code bootstrap qui doit être exécutée pour initialiser le programme mais peut être jetée une fois que cela a été exécuté, ou des sections contenant des informations de débogage (qui n'ont pas besoin d'être chargées en mémoire à moins que vous n'ayez exécuté le programme dans un débogueur). Une autre section courante est une section de données réadonnées:
.rodata: contient des données non inscriptibles, par ex. toutes les chaînes ou les données de const dans votre programme.
De plus, les processeurs peuvent appliquer une protection à la mémoire, telle que la mémoire lisible / écritable / exécutable. Avoir des sections séparées permet d'appliquer facilement ces protection de la mémoire. Par exemple. Le code doit être exécutable, mais que les données soient exécutables pourraient être une mauvaise idée. Lecture seule Les sections peuvent également être plus facilement partagées entre autres processus, les sections de code et de mémoire réadonnées peuvent être partagées entre plusieurs instances du programme. Si des parties de la section de texte devaient être échangées, elles peuvent simplement être jetées, car elles résident déjà dans l'exécutable lui-même, alors que les sections de données / BSS ne peuvent pas, elles doivent être échangées dans une zone d'échange spéciale.
@nos qu'entendez-vous par «mémoire qui doit être zéro au démarrage du programme »?
Non, je pense que vous avez compris le concept de segmentation incorrect, non seulement utilisé dans l'assemblage, toutes les langues de haut niveau spécifiques à une machine (comme C, C ++, Basic, Pascal, etc.) utilisent des segments en interne.
Parce que tous les programmes C et C ++ sont compilés à la langue d'assemblage par le compilateur GNU (dans le cas de Ubuntu), le compilateur mettra l'approche Data S sur des segments appropriés et l'assembleur de gaz convertira cet assemblage. pour objet d'octets de code.
Sections, non segments. C'est une caractéristique du format de fichier exécutable. C'est le segment du code 16 bits, pas clair si c'est votre cas.
Section et segment sont des synonymes (voir la documentation NASM)