Les images finales produites par les compilateurs contiennent à la fois un fichier bin et un fichier ELF au format de chargeur étendu, quelle est la différence entre les deux, et surtout l'utilité du fichier ELF.
Un fichier Bin est un fichier binaire pur, qui ne comporte pas de corrections ou de relocalisations de mémoire. Il est plus que probable qu'il comporte des instructions explicites pour être chargé à une adresse mémoire spécifique. Considérant que....
ELF sont des fichiers Executable Linkable Format qui consistent en une table de recherche de symboles et de relocalisation, c'est-à-dire qu'ils peuvent être chargés à n'importe quelle adresse mémoire par le noyau et automatiquement, tous les symboles utilisés, sont ajustés au décalage de cette adresse mémoire où ils ont été chargés. Habituellement, les fichiers ELF comportent un certain nombre de sections, telles que 'data', 'text', 'bss', pour n'en citer que quelques-unes... c'est dans ces sections que le run-time peut calculer où ajuster dynamiquement les références mémoire du symbole au moment de l'exécution.
"il est plus que probable qu'il ait des instructions explicites pour être chargé à une adresse mémoire spécifique" : cela signifie-t-il que le processus de génération du fichier bin ajoute du code supplémentaire pour charger les données à une adresse spécifique ?
D'après ce que j'ai appris, le fichier bin revient à exécuter le programme à partir de l'offset 0 et le segment de données est intégré à l'intérieur. Si cela est faux, veuillez me corriger.
Un fichier bin est juste les bits et les octets qui vont dans la rom ou une adresse particulière à partir de laquelle vous allez exécuter le programme. Vous pouvez prendre ces données et les charger directement telles quelles, mais vous devez savoir quelle est l'adresse de base car elle n'est généralement pas indiquée.
Un fichier elf contient les informations du binaire mais il est entouré de beaucoup d'autres informations, éventuellement des informations de débogage, des symboles, permettant de distinguer le code des données dans le binaire. Permet d'avoir plus d'un morceau de données binaires (lorsque vous videz l'un de ces fichiers dans un fichier bin, vous obtenez un gros fichier bin avec des données de remplissage pour le faire passer au bloc suivant). Vous indique la quantité de données binaires que vous avez et la quantité de données bss qui doivent être initialisées à des zéros (les outils gnu ont des problèmes pour créer correctement les fichiers bin).
Le format de fichier elf est un standard, arm publie ses améliorations/variations sur le standard. Je recommande à tout le monde d'écrire un programme d'analyse elf pour comprendre ce qu'il y a dedans, ne vous embêtez pas avec une bibliothèque, il est assez simple d'utiliser les informations et les structures dans la spécification. Cela aide à surmonter les problèmes de gnu en général en créant des fichiers .bin ainsi qu'en déboguant des scripts de linker et d'autres choses qui peuvent aider à gâcher votre sortie bin ou elf.
Une explication claire ! Alors comment le chargeur saura-t-il où charger le bin ? Si nous prenons le cas d'un simple bin qui imprimerait de l'ascii sur l'écran VGA sur X86, devrions-nous compiler le elf avec un linker qui a son _start fixé à quelque chose comme 0x7C00 ? Ce que je comprends de la réponse, c'est que le linker peut fixer le start à n'importe quelle valeur que nous perdons en convertissant le elf en bin. C'est le chargeur du BIOS qui a probablement codé en dur l'adresse de chargement 0x7C00 qui fait le travail de chargement à la bonne adresse. Pouvez-vous me corriger si je me trompe ?
0x7C00 sonne comme une chose de bootloader qui n'utilise pas nécessairement elf. c'est une question générique. un système d'exploitation aurait des règles pour les espaces d'adresse (virtuels), la chaîne d'outils devrait être ciblée sur les règles de ce système d'exploitation, puis le format de fichier indiquerait les éléments chargeables avec des adresses plus un point d'entrée une fois chargé, plus d'autres choses. elf est juste un conteneur, comme une boîte, vous devez l'emballer correctement pour le cas d'utilisation ciblé.
Si vous voulez imprimer de l'ascii sur le vga, vous écrivez un fichier programme Pour faire cela, il faut avoir des données ou générer mathématiquement les données à la volée ou une combinaison des deux, puis charger ce programme dans l'espace de code défini par le système d'exploitation, et enfin l'exécuter. En général, on ne fourre pas de données directement dans un périphérique physique, et il est rare que le système d'exploitation vous laisse faire cela de toute façon, ou permette à son chargeur de le faire.
Quelques ressources :
Le format ELF est généralement la sortie par défaut de la compilation. Si vous utilisez les chaînes d'outils GNU, vous pouvez les traduire au format binaire en utilisant objcopy, par exemple :
arm-elf-objcopy -O binary [elf-input-file] [binary-output-file]ou en utilisant l'utilitaire fromELF (intégré dans la plupart des IDE tels que ADS) :
fromelf -bin -o [binary-output-file] [elf-input-file]
Bin est l'aspect final de la mémoire avant que le CPU ne commence à l'exécuter.
ELF en est une version tronquée/compressée, que le CPU/MCU ne peut donc pas exécuter directement.
L'éditeur de liens (dynamique) doit d'abord inverser suffisamment cela (et donc modifier les décalages pour les ramener aux positions correctes).
Mais il n'y a pas de linker/OS sur le MCU, donc vous devez flasher le bin à la place.
De plus, Ahmed Gamal a raison .
La compilation et l'édition de liens sont des étapes distinctes ; l'ensemble du processus est appelé "construction", c'est pourquoi la collection de compilateurs GNU a des exécutables séparés :
Un pour le compilateur (qui produit techniquement l'assemblage), un autre pour l'assembleur (qui produit le code objet au format ELF), puis un pour le linker (qui combine plusieurs fichiers objets en un seul fichier ELF), et enfin, au moment de l'exécution, il y a le linker dynamique, qui transforme effectivement un elf en bin, mais uniquement en mémoire, pour que le CPU puisse l'exécuter.
Notez qu'il est courant de se référer à l'ensemble du processus en tant que "compilation" (comme dans le nom de GCC lui-même), mais cela entraîne ensuite une confusion lorsque les détails sont discutés, comme dans ce cas, et Ahmed a voulu clarifier les choses.
C'est un problème courant dû à la nature inexacte du langage humain lui-même.
Pour éviter toute confusion, GCC produit le code objet (après avoir utilisé l'assembleur en interne) en utilisant le format ELF. L'éditeur de liens prend simplement plusieurs d'entre eux (avec une extension .o), et produit un seul résultat combiné, probablement même en les compressant (dans "a.out").
Mais tous, même les ".so" sont ELF. C'est comme plusieurs documents Word, chacun se terminant par ".chapter", tous étant combinés en un ".book" final, où tous les fichiers utilisent techniquement le même standard/format et auraient donc pu avoir ".docx" comme extension.
Le bac revient alors à convertir le livre en un fichier ".txt" en ajoutant autant d'espaces que nécessaire pour être équivalent à la taille du livre final (imprimé sur une seule bobine), avec des emplacements pour toutes les images à superposer.
Dévalorisé car il ne répond pas à la question et n'est pas nécessairement correct. Au sens large, la compilation inclut la création de liens. Citée dans le ld documentation : Habituellement, la dernière étape de la compilation d'un programme est d'exécuter ld.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Voici ce que dit la NASM . Ce n'est pas spécifique à ARM, mais il s'agit probablement du même concept. Par exemple, si vous compilez un fichier contenant seulement
NOPsans-f(ou-fbin), il se compile en un seul octet0x90au lieu d'un conteneur ELF de 400 octets avec-felf32. Donc juste le code brut, pas de métadonnées de conteneur. NASM dit qu'il est surtout utilisé pour les .COM de MS-DOS et les . .SYS des fichiers.sectionsont généralement ignorées et ne génèrent qu'un alignement.0 votes
C'est l'une des façons dont les fichiers bin peuvent être utiles : pour créer un secteur de démarrage afin de déployer des systèmes d'exploitation : stackoverflow.com/a/32483545/895245