Déménagement (informatique) - Relocation (computing)

La relocalisation est le processus d'attribution d'adresses de charge pour le code et les données dépendant de la position d'un programme et d'ajustement du code et des données pour refléter les adresses attribuées. Avant l'avènement des systèmes multiprocessus, et toujours dans de nombreux systèmes embarqués, les adresses des objets étaient absolues à partir d'un emplacement connu, souvent zéro. Étant donné que les systèmes de multitraitement relient et basculent dynamiquement entre les programmes, il est devenu nécessaire de pouvoir déplacer des objets à l'aide d' un code indépendant de la position . Un éditeur de liens effectue généralement la relocalisation en conjonction avec la résolution de symboles , le processus de recherche de fichiers et de bibliothèques pour remplacer les références symboliques ou les noms de bibliothèques par des adresses réellement utilisables en mémoire avant d'exécuter un programme.

La relocalisation est généralement effectuée par l'éditeur de liens au moment de la liaison , mais elle peut également être effectuée au moment du chargement par un chargeur de relocalisation , ou au moment de l'exécution par le programme en cours d'exécution lui-même . Certaines architectures évitent entièrement la relocalisation en reportant l' attribution d'adresses au moment de l'exécution ; c'est ce qu'on appelle l' arithmétique d'adresse zéro .

Segmentation

Les fichiers objets sont segmentés en différents types de segments de mémoire . Les exemples de segments incluent le segment de code (.text) , le segment de données initialisé (.data) , le segment de données non initialisé (.bss ) ou autres.

Tableau de relocalisation

La table de relocalisation est une liste de pointeurs créée par le traducteur (un compilateur ou un assembleur ) et stockée dans l'objet ou le fichier exécutable. Chaque entrée de la table, ou "fixup", est un pointeur vers une adresse absolue dans le code objet qui doit être modifiée lorsque le chargeur déplace le programme afin qu'il se réfère à l'emplacement correct. Les correctifs sont conçus pour prendre en charge la relocalisation du programme en tant qu'unité complète. Dans certains cas, chaque correction dans la table est elle-même relative à une adresse de base de zéro, donc les corrections elles-mêmes doivent être modifiées au fur et à mesure que le chargeur se déplace dans la table.

Dans certaines architectures, une correction qui franchit certaines limites (comme une limite de segment) ou qui n'est pas alignée sur une limite de mot est illégale et signalée comme une erreur par l'éditeur de liens.

DOS et Windows 16 bits

Les pointeurs distants ( pointeurs 32 bits avec segment :offset, utilisés pour adresser l' espace mémoire 20 bits de 640 Ko disponible pour les programmes DOS ), qui pointent vers du code ou des données dans un exécutable DOS ( EXE ), n'ont pas de segments absolus, car le l' adresse réelle du code/des données dépend de l'endroit où le programme est chargé dans la mémoire et cela n'est connu qu'une fois le programme chargé.

Au lieu de cela, les segments sont des valeurs relatives dans le fichier DOS EXE. Ces segments doivent être corrigés, lorsque l'exécutable a été chargé en mémoire. Le chargeur EXE utilise une table de relocalisation pour trouver les segments qui doivent être ajustés.

Windows 32 bits

Avec les systèmes d'exploitation Windows 32 bits, il n'est pas obligatoire de fournir des tables de relocalisation pour les fichiers EXE, car ils sont la première image chargée dans l'espace d'adressage virtuel et seront donc chargés à leur adresse de base préférée.

Pour les deux DLL et EXE qui optent dans la répartition aléatoire de mise en page de l' espace d'adressage (ASLR) - une exploit technique d'atténuation introduite avec Windows Vista, les tables de réinstallation deviennent à nouveau obligatoire en raison de la possibilité que le binaire peut être déplacé dynamiquement avant d' être exécuté, même si elles sont toujours la première chose chargée dans l'espace d'adressage virtuel.

Windows 64 bits

Lors de l'exécution de binaires 64 bits natifs sur Windows Vista et versions ultérieures, l'ASLR est obligatoire et les sections de relocalisation ne peuvent donc pas être omises par le compilateur.

Systèmes de type Unix

Le format exécutable ELF ( Executable and Linkable Format ) et le format de bibliothèque partagée utilisés par la plupart des systèmes de type Unix permettent de définir plusieurs types de relocalisation.

Procédure de déménagement

L'éditeur de liens lit les informations de segment et les tables de relocalisation dans les fichiers objets et effectue la relocalisation en :

fusion de tous les segments de type commun en un seul segment de ce type
attribuer des adresses d'exécution uniques à chaque section et à chaque symbole, en donnant à tous les codes (fonctions) et données (variables globales) des adresses d'exécution uniques
en se référant à la table de relocalisation pour modifier les symboles afin qu'ils pointent vers les bonnes adresses d'exécution.

Exemple

L'exemple suivant utilise Donald Knuth de MIX architecture et langage assembleur MIXAL. Les principes sont les mêmes pour n'importe quelle architecture, même si les détails changeront.

(A) Le programme SUBR est compilé pour produire un fichier objet (B), affiché à la fois sous forme de code machine et d'assembleur. Le compilateur peut démarrer le code compilé à un emplacement arbitraire, souvent l'emplacement 1 comme indiqué. L'emplacement 13 contient le code machine pour l'instruction de saut à l'instruction ST à l'emplacement 5.
(C) Si SUBR est ultérieurement lié à un autre code, il peut être stocké à un emplacement autre que 1. Dans cet exemple, l'éditeur de liens le place à l'emplacement 120. L'adresse dans l'instruction de saut, qui est maintenant à l'emplacement 133, doit être déplacée pour pointer vers le nouvel emplacement du code pour l'instruction ST , maintenant 125. [1 61 montré dans l'instruction est la représentation du code machine MIX de 125].
(D) Lorsque le programme est chargé en mémoire pour s'exécuter, il peut être chargé à un emplacement autre que celui attribué par l'éditeur de liens. Cet exemple montre SUBR maintenant à l'emplacement 300. L'adresse dans l'instruction de saut, maintenant à 313, doit être déplacée à nouveau afin qu'elle pointe vers l'emplacement mis à jour de ST , 305. [4 49 est la représentation de la machine MIX de 305].

Voir également

Les références

Lectures complémentaires

Johnson, Glenn (1975-12-21) [1975-11-13], 11/34 Memory Management Basic Logic test , Digital Equipment Corporation (DEC), MAINDEC-11-DFKTA-AD , récupéré 2017-08-19
Kildall, Gary Arlen (février 1978). "Une technique simple pour la relocalisation statique de code machine absolu" . Journal du Dr Dobb sur la callisthénie informatique et l'orthodontie . Société informatique du peuple . 3 (2) : 10-13 (66-69). ISBN 0-8104-5490-4. #22. Archivé de l'original le 2017-09-09 . Récupéré le 2017-08-19 . [4] [5] [6] (Cette méthode de "redimensionnement", appelée relocalisation des limites de la page , pourrait être appliquée de manière statique à une image disque CP/M-80 à l'aide de MOVCPM [ pl ] afin de maximiser le TPA pour l'exécution des programmes. Il a également été utilisé dynamiquement par le débogueur CP/M Dynamic Debugging Tool (DDT) pour se relocaliser dans une mémoire supérieure. La même approche a été développée indépendamment par Bruce Van Natta d' IMS Associates pour produire du code PL/M relogeable . En tant que relocalisation de limite de paragraphe , une autre variante de cette méthode a ensuite été utilisée par les TSR à auto-déplacement dynamique HMA comme KEYB , SHARE et NLSFUNC sous DR DOS 6.0 et versions ultérieures. Une méthode granulaire beaucoup plus sophistiquée et au niveau de l'octet basée sur une approche quelque peu similaire a été conçue et mise en œuvre indépendamment par Matthias R. Paul et Axel C. Frinke pour leur élimination dynamique du code mort afin de minimiser dynamiquement l'empreinte d'exécution des pilotes résidents et des TSR (comme FreeKEYB).)
Huitt, Robert; Eubanks, Gordon ; Rolander, Thomas "Tom" Alan ; Lois, David ; Michel, Howard E.; Halla, Brian ; Wharton, John Harrison ; Berg, Brian; Su, Weilian ; Kildall, Scott ; Kampe, Bill (2014-04-25). Lois, David (éd.). "Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication" (PDF) (transscription vidéo). Pacific Grove, Californie, États-Unis : Musée d'histoire de l'informatique . Numéro de référence CHM : X7170.2014. Archivé (PDF) de l'original le 2014-12-27 . Récupéré le 2020-01-19 . […] Lois : […] « relocalisation dynamique » de l'OS. Pouvez-vous nous dire ce que c'est et pourquoi c'était important ? […] Eubanks : […] ce que Gary a fait […] était […] ahurissant. […] Je me souviens du jour où à l' école il est venu bondir dans le laboratoire et il a dit, j'ai trouvé comment déménager. Il a profité du fait que le seul octet allait toujours être l' octet de poids fort . Et donc il a créé un bitmap . […] peu importait la quantité de mémoire dont disposait l'ordinateur, le système d'exploitation pouvait toujours être déplacé dans la mémoire haute. Par conséquent, vous pourriez commercialiser cela […] sur des machines de différentes quantités de mémoire. […] vous ne pouviez pas vendre un 64K CP/M et un 47K CP/M. Ce serait juste ridicule d'avoir une compilation difficile dans les adresses. Alors Gary a compris cela une nuit, probablement au milieu de la nuit en pensant à quelque chose de codage, et cela a vraiment rendu CP/M possible de commercialiser. Je pense vraiment que sans ce déménagement, cela aurait été un problème très difficile. Pour amener les gens à l'acheter, cela leur semblerait compliqué, et si vous ajoutiez plus de mémoire, vous devriez aller chercher un système d'exploitation différent. […] Intel […] avait inversé les octets , à droite, pour les adresses mémoire. Mais ils étaient toujours au même endroit, vous pouviez donc le déplacer sur une limite de 256 octets , pour être précis. Vous pouvez donc toujours le déplacer avec juste un bitmap d'où ces […] Lois : Certainement l'explication la plus éloquente que j'aie jamais eue de la relocalisation dynamique […] [7] [8] (33 pages)
Lieber, Eckhard ; von Massenbach, Thomas (1987). "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". c't - magazin für computertechnik (partie 1) (en allemand). Heise Verlag . 1987 (1) : 124-135 ; Lieber, Eckhard ; von Massenbach, Thomas (1987). "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". c't - magazin für computertechnik (partie 2) (en allemand). Heise Verlag . 1987 (2) : 78-85 ; Huck, Alex (2016-10-09). "RSM pour CP/M 2.2" . Ordinateur domestique DDR (en allemand). Archivé de l'original le 2016-11-25 . Récupéré le 25/11/2016 .
Guzis, Charles "Chuck" P. (2015-03-16). "Re: Programmation en langage assembleur CP/M" . Forum informatique d'époque . Genre : CP/M et MP/M. Archivé de l'original le 2020-02-01 . Récupéré le 01-02-2020 . […] Vous êtes-vous déjà demandé comment fonctionne MOVCPM [ pl ] ? Étant donné que le BDOS et le CCP sont en mémoire haute, au-dessus de l'application utilisateur, les adresses doivent être modifiées à chaque fois que la taille de la mémoire système est modifiée. Cela nécessite maintenant de déplacer les adresses dans le code 8080 , car l'adressage relatif ne fait pas partie du matériel. Sans implémenter un assembleur et un chargeur de relocalisation à part entière, comment procéder ? C'est en fait assez intelligent et MP/M utilise même ce schéma pour construire ses fichiers transférables par page. Vous assemblez simplement le programme source deux fois avec la deuxième origine d'assemblage 100H (256 octets) supérieure à la première. Les deux images binaires sont ensuite comparées, octet par octet, et une carte construite d'où les paires d'octets diffèrent en valeur d'exactement 100H. Le résultat est une liste d'emplacements où la valeur de relocalisation doit être ajustée si l'emplacement d'un programme en mémoire doit être déplacé. MP/M appelle ce genre de fichier PRL (page relocalisable), mais je ne sais pas si CP/M 2.2 a jamais inventé un nom pour cela. […]
Guzis, Charles "Chuck" P. (2015-07-29). "Re : Comment fonctionne MOVCPM.COM ?" . Forum informatique d'époque . Genre : CP/M et MP/M. Archivé de l'original le 2020-02-01 . Récupéré le 01-02-2020 . […] MOVCPM [ pl ] utilise un premier type de format PRL. Fondamentalement, CP/M est assemblé deux fois ; la deuxième fois est un décalage de 100H octets. Les deux binaires sont comparés et un bitmap est construit. Un bit défini implique que l' octet de poids fort d'une adresse doit être ajusté. Les octets d'adresse de poids faible ne sont pas affectés ; par conséquent, "Fichier relocalisable de page". Chaque octet du bitmap correspond à 8 octets des données binaires. […] Ainsi, tout ce qui doit être déplacé dans MOVCPM fait partie de l'image et de son bitmap de relocalisation. […]
Guzis, Charles "Chuck" P. (2016-11-08). "Re : Est-il sûr d'utiliser RST 28h dans les programmes d'assemblage CP/M ?" . Forum informatique d'époque . Genre : CP/M et MP/M. Archivé de l'original le 2020-02-01 . Récupéré le 01-02-2020 . […] J'ai référencé les fichiers PRL et comment ils ont commencé à l' origine avec MOVCPM [ pl ] , mais sont devenus une partie intégrante de MP/M et CP/M 3.0 . Mais les fichiers PRL utilisent une carte de bits dans laquelle chaque bit correspond à un emplacement mémoire ; un bit indique qu'un décalage de relocalisation de page doit être ajouté à l'emplacement mémoire correspondant. Si vous avez très peu de références de mémoire absolues (par opposition à des références relatives), vous pouvez utiliser une liste de pointeurs (2 octets par référence) plutôt qu'un bitmap. C'est peu probable dans le code 8080 qui n'a pas de sauts relatifs, mais peut être une considération pour le code Z80 . L'astuce pour le découvrir rapidement est d'assembler votre programme deux fois ; la deuxième fois décalée de 100H, puis comparez les deux binaires. L'avantage de la relocalisation à l' exécution est que vous n'avez pas à encourir de pénalité pour le code qui tente de contourner le problème de relocalisation - pas de "trucs" ; il suffit d'écrire du code direct. […]
Roth, Richard L. (février 1978) [1977]. « La relocalisation ne consiste pas seulement à déplacer des programmes » . Journal du Dr Dobb sur la callisthénie informatique et l'orthodontie . Ridgefield, Californie, États-Unis : People's Computer Company . 3 (2) : 14-20 (70-76). ISBN 0-8104-5490-4. #22. Archivé de l'original le 2019-04-20 . Récupéré le 2019-04-19 .
Calingaert, Peter (1979) [1978-11-05]. "8.2.2 Déplacement du chargeur". Écrit à l' Université de Caroline du Nord à Chapel Hill . Dans Horowitz, Ellis (éd.). Assembleurs, compilateurs et traduction de programmes . Série de génie logiciel informatique (1ère impression, 1ère éd.). Potomac, Maryland, États-Unis : Computer Science Press, Inc. pp. 237 –241. ISBN 0-914894-23-4. ISSN 0888-2088 . LCCN 78-21905 . Récupéré le 20/03/2020 . (2+xiv+270+6 pages)
Le format de fichier Microsoft OBJ . Microsoft , Services d'assistance produit. Note d'application SS0288. Archivé de l'original le 2017-09-09 . Récupéré le 21/08/2017 .
Tanenbaum, André Stuart ; Bos, Herbert (2015). Systèmes d'exploitation modernes (4 éd.). Pearson Education Inc. ISBN 978-0-13359162-0.
Elliott, John C. (2012-06-05) [2000-01-02]. "Format de fichier PRL" . seasip.info . Archivé de l'original le 2020-01-26 . Récupéré le 2020-01-26 . […] Un fichier PRL est un fichier binaire transférable, utilisé par MP/M et CP/M Plus pour divers modules autres que les fichiers .COM . Le format de fichier est également utilisé pour les fichiers FID sur l' Amstrad PCW . Il existe plusieurs formats de fichiers qui utilisent des versions de PRL : SPR (System PRL), RSP (Resident System Process). LINK-80 peut également produire des fichiers OVL (overlay), qui ont un en-tête PRL mais ne peuvent pas être déplacés. Les pilotes GSX sont au format PRL ; il en va de même pour les extensions système résidentes (.RSX). […] [9]
Elliott, John C. (2012-06-05) [2000-01-02]. "Format REL Microsoft" . seasip.info . Archivé de l'original le 2020-01-26 . Récupéré le 2020-01-26 . […] Le format REL est généré par le M80 de Microsoft et le RMAC de Digital Research . […]
feilipu (2018-09-05) [2018-09-02]. "Prise en charge de PRL, exécutable transférable de page pour MP/M" . z88dk . Archivé de l'original le 2020-02-01 . Récupéré le 2020-01-26 . […] À partir des fichiers Microsoft .REL assemblés , l'éditeur de liens doit générer un exécutable au format .PRL pour MP/M . Le format .PRL est essentiellement un fichier .COM avec des informations supplémentaires pour permettre au programme et à ses données d'être déplacés sur n'importe quelle page. A quoi ressemble un fichier .PRL ? Les premiers octets sont la taille du programme, suivis de l'origine du programme à 0x0100. Après le programme, un masque bit par octet est ajouté pour permettre au système MP/M de savoir quels octets du programme doivent être modifiés lorsque le programme est déplacé. Comment l'éditeur de liens fait-il cela sans désassembler l'ensemble de l'application ? Au préalable le programme est lié pour deux origines différentes 0x0100 et 0x0200, à partir des objets .REL. L'astuce de l'éditeur de liens consiste simplement à reconnaître quels octets dans les deux versions de l'exécutable diffèrent. Ces octets sont ensuite enregistrés dans le masque de bits stocké après l'exécutable, et le programme .PRL final est conçu pour s'exécuter à partir de 0x0100 plus son décalage de page. La même astuce est faite pour les fichiers exécutables .RSP et .SPR, sauf que ces deux formats renoncent au décalage et s'exécutent à partir de 0x0000 plus leur décalage de page. […]
Frères, Hardin (avril 1983). « Comprendre le code transférable » . 80 Micro . L'étape suivante. 1001001, Inc. (39) : 38 , 40, 42, 45. ISSN 0744-7868 . Récupéré le 2020-02-06 . [10] [11]
Frères, Hardin (avril 1985). « Programmes déplaçables : les hobo de la micro-informatique » . 80 Micro . L'étape suivante. CW Communications/Peterborough, Inc. (63) : 98 , 100, 102-103. ISSN 0744-7868 . Récupéré le 2020-02-06 . [12] [13]
Mitchell, Bridger (juillet-août 1988). Carlson, Art (éd.). "Z3PLUS & Relocation - Informations sur ZCPR3PLUS, et comment écrire le code Z80 d'auto-relocalisation" . The Computer Journal (TCJ) - Programmation, Support utilisateur, Applications . CP/M avancé. Columbia Falls, Montana, États-Unis (33) : 9 –15. ISSN 0748-9331 . arche:/13960/t36121780 . Récupéré le 2020-02-09 . [14] [15]
Sage, Jay (septembre-octobre 1988). Carlson, Art (éd.). "ZCPR3 Corner - Plus d'informations sur le code transférable, les fichiers PRL, les programmes ZCPR34 et Type-4" . The Computer Journal (TCJ) - Programmation, Support utilisateur, Applications . CP/M avancé. Columbia Falls, Montana, États-Unis (34) : 20 –25. ISSN 0748-9331 . arche:/13960/t0ks7pc39 . Récupéré le 2020-02-09 . [16] [17]
Ganssle, Jack (février 1992). "Ecriture de code relocalisable - Certains codes intégrés doivent s'exécuter à plus d'une adresse" . Programmation des systèmes embarqués . Le groupe Ganssle - Perfectionner l'art de construire des systèmes embarqués / TGG. Archivé de l'original le 2019-07-18 . Récupéré le 20-02-2020 .

Languages

In other projects