De uiteindelijke afbeeldingen geproduceerd door compliers bevatten zowel het bin-bestand als het uitgebreide loader-formaat ELF-bestand, wat het verschil tussen de twee is, vooral het nut van het ELF-bestand.
Antwoord 1, autoriteit 100%
Een Bin-bestand is een puur binair bestand zonder geheugenverbeteringen of -verplaatsingen, het heeft meer dan waarschijnlijk expliciete instructies om op een specifiek geheugenadres te worden geladen. Terwijl ….
ELF-bestanden zijn Executable Linkable Format dat bestaat uit een symboolzoekopdracht en een verplaatsbare tabel, dat wil zeggen, het kan door de kernel op elk geheugenadres worden geladen en automatisch worden alle gebruikte symbolen aangepast aan de offset van dat geheugenadres waar het in was geladen. Gewoonlijk hebben ELF-bestanden een aantal secties, zoals ‘data’, ‘text’, ‘bss’, om er maar een paar te noemen … het is binnen die secties waar de runtime kan berekenen waar de geheugenreferenties van het symbool moeten worden aangepast dynamisch tijdens runtime.
Antwoord 2, autoriteit 44%
Een bin-bestand is slechts de bits en bytes die in de rom gaan of een bepaald adres van waaruit u het programma gaat uitvoeren. Je kunt deze gegevens nemen en direct laden zoals ze zijn, je moet wel weten wat het basisadres is, want dat staat er normaal niet in.
Een elf-bestand bevat de bin-informatie, maar het is omgeven door veel andere informatie, mogelijke debug-info, symbolen, kan code onderscheiden van gegevens binnen het binaire bestand. Staat meer dan één stuk binaire gegevens toe (wanneer u een van deze naar een prullenbak dumpt, krijgt u één groot bin-bestand met opvulgegevens om het naar het volgende blok te vullen). Vertelt je hoeveel binair je hebt en hoeveel bss-gegevens er zijn die naar nullen willen worden geïnitialiseerd (gnu-tools hebben problemen om bin-bestanden correct te maken).
Het elf-bestandsformaat is een standaard, arm publiceert de verbeteringen/variaties op de standaard. Ik raad iedereen aan een elf-ontledingsprogramma te schrijven om te begrijpen wat er in zit, doe geen moeite met een bibliotheek, het is vrij eenvoudig om gewoon de informatie en structuren in de specificatie te gebruiken. Helpt bij het oplossen van gnu-problemen in het algemeen bij het maken van .bin-bestanden en het debuggen van linkerscripts en andere dingen die kunnen helpen om uw bin- of elf-uitvoer te verknoeien.
Antwoord 3, autoriteit 30%
enkele bronnen:
- ELF voor de ARM-architectuur
http://infocenter.arm.com/help/topic /com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf - ELF van wiki
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
ELF-indeling is over het algemeen de standaarduitvoer van compileren.
als u GNU-toolketens gebruikt, kunt u deze vertalen naar een binair formaat door objcopy te gebruiken, zoals:
arm-elf-objcopy -O binary [elf-input-file] [binary-output-file]
of met het hulpprogramma fromELF (in de meeste IDE’s zoals ADS ingebouwd):
fromelf -bin -o [binary-output-file] [elf-input-file]
Antwoord 4
bin is de laatste manier waarop het geheugen eruitziet voordat de CPU het begint uit te voeren.
ELF is een opgeknipte/gecomprimeerde versie daarvan, die de CPU/MCU dus niet rechtstreeks kan uitvoeren.
De (dynamische) linker moet dat eerst voldoende omkeren (en dus offsets terug naar de juiste posities aanpassen).
Maar er is geen linker/OS op de MCU, dus je moet in plaats daarvan de prullenbak flashen.
Bovendien Ahmed Gamal heeft gelijk.
Compileren en koppelen zijn afzonderlijke fasen; het hele proces wordt “bouwen” genoemd, vandaar dat de GNU Compiler Collection afzonderlijke uitvoerbare bestanden heeft:
Eén voor de compiler (die technisch de assembly uitvoert), een andere voor de assembler (die objectcode in het ELF-formaat uitvoert),
dan een voor de linker (die verschillende objectbestanden combineert in een enkel ELF-bestand), en ten slotte, tijdens runtime, is er de dynamische linker,
die een elf effectief in een prullenbak verandert, maar puur in het geheugen, zodat de CPU kan werken.
Merk op dat het gebruikelijk is om naar het hele proces te verwijzen als “compileren” (zoals in de naam van GCC zelf), maar dat veroorzaakt dan verwarring wanneer de details worden besproken,
zoals in dit geval, en Ahmed verduidelijkte.
Het is een veelvoorkomend probleem vanwege de onnauwkeurige aard van de menselijke taal zelf.
Om verwarring te voorkomen, voert GCC objectcode uit (na intern gebruik van de assembler) met behulp van het ELF-formaat.
De linker neemt er gewoon meerdere (met een .o-extensie) en produceert een enkel gecombineerd resultaat, waarschijnlijk zelfs comprimerend (in “a.out”).
Maar ze zijn allemaal, zelfs ‘.so’, ELF.
Het is net als verschillende Word-documenten, die elk eindigen op “.chapter”, die allemaal worden gecombineerd tot een definitief “.book”,
waarbij alle bestanden technisch gezien dezelfde standaard/indeling gebruiken en daarom “.docx” als extensie hadden kunnen hebben.
De prullenbak is dan vergelijkbaar met het converteren van het boek naar een “.txt”-bestand, terwijl er zoveel witruimte wordt toegevoegd als nodig is om gelijk te zijn aan de grootte van het uiteindelijke boek (afgedrukt op een enkele spoel),
met plaatsen voor alle foto’s om over elkaar heen te leggen.
Antwoord 5
Ik wil hier alleen een punt corrigeren. ELF-bestand wordt geproduceerd door de Linker, niet door de compiler.
De Compiler-missie eindigt na het produceren van de objectbestanden (*.o) uit de broncodebestanden. Linker koppelt alle .o-bestanden aan elkaar en produceert de ELF.