Quelle est la différence entre les fichiers ELF et les fichiers bin?


97

Les images finales produites par les compleurs contiennent à la fois un fichier bin et un fichier ELf au format chargeur étendu, quelle est la différence entre les deux, en particulier l'utilité du fichier ELF.


C'est ce que le NASM a à dire . Pas spécifique à ARM, mais probablement le même concept. Par exemple, si vous compilez un fichier contenant juste NOPsans -f(ou -fbin), il se compile en un seul octet 0x90, au 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 principalement utilisé pour les fichiers MS-DOS .COM et .SYS . sectionles directives sont généralement ignorées et ne génèrent qu'un alignement.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

C'est une façon dont les fichiers bin peuvent être utiles: pour créer un secteur de démarrage pour déployer des systèmes d'exploitation: stackoverflow.com/a/32483545/895245
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Réponses:


94

Un fichier Bin est un fichier binaire pur sans réparation ni déplacement de mémoire, il a plus que probablement des instructions explicites à charger à une adresse mémoire spécifique. Tandis que....

Les fichiers ELF sont un format exécutable pouvant être lié qui se compose d'une recherche de symboles et d'une table déplaçable, c'est-à-dire qu'il peut être chargé à 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ù il a été chargé dans. Habituellement, les fichiers ELF ont un certain nombre de sections, telles que 'data', 'text', 'bss', pour n'en nommer que quelques-unes ... c'est dans ces sections où le run-time peut calculer où ajuster les références mémoire du symbole dynamiquement au moment de l'exécution.


"il est plus que probable qu'il a des instructions explicites à charger à une adresse mémoire spécifique": cela signifie-t-il que le processus de génération de fichier bin ajoute un code supplémentaire pour charger des données à une adresse spécifique?
Penghe Geng

1
Autant que j'ai appris, le fichier bin est comme exécuter le programme à partir de l'offset 0 et le segment de données est intégré à l'intérieur. Si cela ne va pas, veuillez me corriger.
Martin Kersten

@MartinKersten correct, les fichiers bin commencent à partir du décalage 0.
t0mm13b

1
@ t0mm13b Ainsi, les fichiers .elf peuvent être gravés sur un micro-contrôleur comme un fichier .hex normal, mais cela prend plus de mémoire flash, et chaque fois que le micro est réinitialisé, les adresses des sections changent?
Aelgawad

@BlackyDucky, je ne pense pas que ce soit possible. Si un microcontrôleur essayait d'exécuter directement les données ELF, il interpréterait mal les en-têtes et d'autres données comme des instructions, n'est-ce pas?
jacobq

40

Un fichier bin est juste les bits et octets qui entrent dans la rom ou une adresse particulière à partir de laquelle vous exécuterez le programme. Vous pouvez prendre ces données et les charger directement telles quelles, vous devez savoir quelle est l'adresse de base car elle ne s'y trouve normalement pas.

Un fichier elf contient les informations bin mais il est entouré de beaucoup d'autres informations, des informations de débogage possibles, des symboles, peuvent distinguer le code des données dans le binaire. Permet plus d'un morceau de données binaires (lorsque vous en videz un dans un bac, vous obtenez un gros fichier bin avec des données de remplissage pour le remplir dans le bloc suivant). Vous indique la quantité de binaires dont vous disposez et la quantité de données bss qui veulent être initialisées à zéro (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 elfe pour comprendre ce qu'il y a dedans, ne vous embêtez pas avec une bibliothèque, il est assez simple d'utiliser simplement les informations et les structures de la spécification. Aide à surmonter les problèmes de gnu en général en créant des fichiers .bin ainsi qu'en déboguant les scripts de l'éditeur de liens et d'autres choses qui peuvent aider à gâcher votre sortie bin ou elf.


1
0x7C00 ressemble à 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'adressage (virtuels), la chaîne d'outils devrait être ciblée sur ces règles de 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é, et d'autres choses. elf est juste un conteneur, comme une boîte, vous devez l'emballer correctement pour le cas d'utilisation ciblé.
old_timer

1
si vous voulez imprimer des ascii sur le vga, vous écrivez un programme pour faire ce qui a des données ou génère mathématiquement les données à la volée ou une combinaison, puis vous chargez ce programme dans l'espace de code défini par le système d'exploitation, puis exécutez il. vous ne poussez généralement pas les données directement dans un périphérique physique, et c'est le système d'exploitation rare qui vous permettrait de le faire de toute façon, ou autoriser son chargeur à le faire.
old_timer

1
pour le bare metal, surtout si ce fichier elf est le chargeur de démarrage et / ou le premier programme exécuté, le point d'entrée et _start ne sont pas pertinents car vous utilisez le fichier elf comme tremplin vers un outil qui programme le flash (comme openocd over jtag) ou par le biais de n'importe quoi-quel-que-objcopy -O binaire file.elf file.bin et puis ce fichier est en quelque sorte chargé dans le flash. Je ne suis pas parti et j'ai essayé un chargeur de démarrage sur x86, mais supposons que le bios ne peut pas analyser les fichiers elf, il faudrait donc également une image mémoire. donc un fichier bin de type binaire -O
old_timer

1
l'entité distincte est le matériel / la logique ou une autre conception. pour les systèmes d'exploitation, le système d'exploitation établit les règles, pour un microcontrôleur, la conception de la puce / du processeur établit les règles. par exemple, s'il y a une table vectorielle et que les vecteurs pointent vers les gestionnaires, vous devez rouler tout cela dans votre script de l'éditeur de liens, etc. pour que les données chargeables soient destinées au flash sur lequel l'objet démarre.
old_timer

1
Pour élargir le fait que votre cible a des règles, que ce soit un système d'exploitation ou un processeur ou un chargeur de démarrage multi-étapes, etc. Et vous devez construire votre "binaire" basé sur ces règles, le bootstrap et le linkerscript étant les plus importants. Ensuite, il est très large quant à chaque cible et comment vous appliquez ce binaire et quels formats de fichiers sont pris en charge. En supposant gnu sur un certain nombre de plates-formes de développement hôte, le format de fichier elf est la sortie par défaut et vous utilisez ensuite les outils nécessaires (si les utilitaires / chargeurs spécifiques à la cible) pour extraire ou convertir d'elf en autre chose.
old_timer

30

quelques ressources:

  1. ELF pour l'architecture ARM
    http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf
  2. ELF du wiki
    http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

Le format ELF est généralement la sortie par défaut de la compilation. si vous utilisez des chaînes d'outils GNU, vous pouvez le traduire au format binaire en utilisant objcopy, tel que:

  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]

6
Cela a été ajouté après le détail du dossier bin a répondu, et n'add-on une technique utile dans la pratique. +1 pour ça.
erbdex

-1

Je veux juste corriger un point ici. Le fichier ELF est produit par l'éditeur de liens, pas par le compilateur.

La mission du compilateur se termine après la production des fichiers objets (* .o) à partir des fichiers de code source. Linker relie tous les fichiers .o ensemble et produit l'ELF.


Évalué parce qu'il ne répond pas à la question ni nécessairement correct. Au sens large, la compilation comprend la liaison. Extrait de la lddocumentation : Habituellement, la dernière étape de la compilation d'un programme consiste à exécuter ld.
bzeaman
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.