Fed binær - Fat binary

For ikke at forveksle med bærbar eksekverbar eller bærbar applikation .

En fed binær (eller multiarchitecture binær ) er et computer -eksekverbart program eller bibliotek, der er blevet udvidet (eller "fedet") med kode, der er native til flere instruktionssæt, som følgelig kan køres på flere processortyper. Dette resulterer i en fil, der er større end en normal binær fil med en arkitektur, og dermed navnet.

Den sædvanlige implementeringsmetode er at inkludere en version af maskinkoden for hvert instruktionssæt, forud for et enkelt indgangspunkt med kode, der er kompatibel med alle operativsystemer, som udfører et spring til den relevante sektion. Alternative implementeringer gemmer forskellige eksekverbare filer i forskellige gafler , hver med sit eget indgangspunkt, der bruges direkte af operativsystemet.

Brugen af ​​fedtbinarier er ikke almindelig i operativsystemsoftware ; der er flere alternativer til at løse det samme problem, f.eks. brugen af ​​et installationsprogram til at vælge en arkitekturspecifik binær på installationstidspunktet (f.eks. med Android flere APK'er), valg af en arkitekturspecifik binær ved kørsel (f.eks. med Plan 9's fagforeningsmapper og GNUsteps fedtpakker ), distribution af software i kildekodeform og kompilering af det på stedet eller brug af en virtuel maskine (f.eks. Med Java ) og Just In Time-kompilering .

Apollo

Apollos sammensatte eksekverbare

I 1988 Apollo Computer 's Domæne / OS SR10.1 indført en ny filtype, "cmpexe" (forbindelse eksekverbar), at bundtet binære filer for Motorola 680x0 og Apollo PRISM eksekverbare.

Æble

Apples fede binære

En fedt-binær ordning glattede Apple Macintoshs overgang, begyndende i 1994, fra 68.000 mikroprocessorer til PowerPC- mikroprocessorer. Mange applikationer til den gamle platform kørte gennemsigtigt på den nye platform under et emuleringsskema i udvikling , men emuleret kode kører generelt langsommere end native kode. Applikationer frigivet som "fede binære filer" tog mere lagerplads, men de kørte i fuld fart på begge platforme. Dette blev opnået ved at pakke både en 68000 -kompileret version og en PowerPC -kompileret version af det samme program i deres eksekverbare filer. Den ældre 68K-kode (CFM-68K eller klassisk 68K) blev fortsat gemt i ressourcegaflen , mens den nyere PowerPC-kode var indeholdt i datagafflen i PEF- format.

Fedt binære filer var større end programmer, der kun understøtter PowerPC eller 68k, hvilket førte til oprettelsen af ​​en række hjælpeprogrammer, der ville fjerne den unødvendige version. I en æra med små harddiske , hvor 80 MB harddiske var en almindelig størrelse, var disse værktøjer undertiden nyttige, da programkode generelt var en stor procentdel af det samlede drevforbrug, og fjernelse af de unødvendige medlemmer af en fed binær ville frigøre en betydelig mængde plads på en harddisk.

NeXT's/Apples multi-arkitektur-binarier

NeXTSTEP Multi-Architecture Binaries

Fat binære filer var en funktion i NeXT 's NeXTStep / OpenStep operativsystem, begyndende med NeXTStep 3.1. I NeXTSTEP blev de kaldt "Multi-Architecture Binaries". Multi-Architecture Binaries var oprindeligt beregnet til at tillade software at kompilere til at køre både på NeXTs Motorola 68k-baserede hardware og på Intel IA-32- baserede pc'er, der kører NeXTSTEP, med en enkelt binær fil til begge platforme. Det blev senere brugt til at tillade OPENSTEP -applikationer at køre på pc'er og de forskellige RISC -platforme, OPENSTEP understøttede. Multi-Architecture Binære filer er i et specielt arkivformat, hvor en enkelt fil gemmer en eller flere Mach-O- underfiler for hver arkitektur understøttet af Multi-Architecture Binary. Hver Multi-Architecture Binary starter med en struktur (struct fat_header), der indeholder to usignerede heltal. Det første heltal ("magi") bruges som et magisk tal til at identificere denne fil som en fed binær. Det andet heltal ("nfat_arch") definerer, hvor mange Mach-O-filer, arkivet indeholder (hvor mange instanser af det samme program til forskellige arkitekturer). Efter dette header er der nfat_arch -antal fat_arch -strukturer (struct fat_arch). Denne struktur definerer den forskydning (fra starten af ​​filen), hvor filen, justeringen, størrelsen og CPU-typen og undertypen, som Mach-O binæren (i arkivet) er målrettet mod, skal findes.

Den version af GNU Compiler Collection, der blev leveret med udviklerværktøjerne, kunne krydskompilere kildekode til de forskellige arkitekturer, som NeXTStep kunne køre på. For eksempel var det muligt at vælge målarkitekturer med flere '-ark'-muligheder (med arkitekturen som argument). Dette var en bekvem måde at distribuere et program til NeXTStep, der kører på forskellige arkitekturer.

Det var også muligt at oprette biblioteker (f.eks. Ved hjælp af libtool) med forskellige målrettede objektfiler.

Mach-O og Mac OS X

Apple Computer erhvervede NeXT i 1996 og fortsatte med at arbejde med OPENSTEP -koden. Mach-O blev det oprindelige objektfilformat i Apples gratis Darwin-operativsystem (2000) og Apples Mac OS X (2001), og NeXT's Multi-Architecture Binaries blev fortsat understøttet af operativsystemet. Under Mac OS X kan Multi-Architecture Binaries bruges til at understøtte flere varianter af en arkitektur, for eksempel at få forskellige versioner af 32-bit kode optimeret til PowerPC G3 , PowerPC G4 og PowerPC 970 generationer af processorer. Det kan også bruges til at understøtte flere arkitekturer, f.eks. 32-bit og 64-bit PowerPC, eller PowerPC og x86 , eller x86-64 og ARM64 .

Apples Universal binære

Hovedartikel: Universal binær
Image
Apple Universal binært logo

I 2005 annoncerede Apple en anden overgang, fra PowerPC -processorer til Intel x86 -processorer . Apple promoverede distribution af nye applikationer, der understøtter både PowerPC og x86 indbygget ved hjælp af eksekverbare filer i Multi-Architecture Binary-format. Apple kalder sådanne programmer " Universal applikationer " og kalder filformatet " Universal binært " som måske en måde at skelne denne nye overgang fra den tidligere overgang eller andre anvendelser af Multi-Architecture Binary format.

Universal binært format var ikke nødvendigt for fremadgående migration af allerede eksisterende native PowerPC-applikationer; fra 2006 til 2011 leverede Apple Rosetta , en PowerPC (PPC) -to-x86 dynamisk binær oversætter , til at spille denne rolle. Imidlertid havde Rosetta en temmelig stejl præstationsomkostning, så udviklere blev opfordret til at tilbyde både PPC- og Intel -binarier ved hjælp af Universal -binarier. Den åbenlyse pris ved Universal binær er, at hver installeret eksekverbar fil er større, men i årene siden udgivelsen af ​​PPC har harddiskplads i høj grad overgået den eksekverbare størrelse; mens en Universal-binær kan være dobbelt så stor som en single-platform-version af den samme applikation, dværger ledige pladsressourcer generelt kodestørrelsen, hvilket bliver et mindre problem. Faktisk vil en Universal-binær applikation ofte være mindre end to enkeltarkitekturapplikationer, fordi programressourcer kan deles snarere end duplikeres. Hvis ikke alle arkitekturer er påkrævet, kan kommandolinjeprogrammerne lipo og ditto bruges til at fjerne versioner fra Multi-Architecture Binary-billedet og derved skabe det, der undertiden kaldes en tynd binær .

Derudover kan Multi-Architecture Binary-eksekverbare filer indeholde kode til både 32-bit og 64-bit versioner af PowerPC og x86, så applikationer kan sendes i en form, der understøtter 32-bit processorer, men som gør brug af det større adresserum og bredere datastier, når de køres på 64-bit processorer.

I versioner af Xcode -udviklingsmiljøet fra 2.1 til 3.2 (kører på Mac OS X 10.4 til Mac OS X 10.6 ) inkluderede Apple hjælpeprogrammer, der gjorde det muligt at målrette applikationer til både Intel- og PowerPC -arkitektur; universelle binære filer kan i sidste ende indeholde op til fire versioner af den eksekverbare kode (32-bit PowerPC, 32-bit x86, 64-bit PowerPC og 64-bit x86 ). PowerPC -understøttelse blev dog fjernet fra Xcode 4.0 og er derfor ikke tilgængelig for udviklere, der kører Mac OS X 10.7 eller nyere.

I 2020 annoncerede Apple endnu en overgang, denne gang fra Intel x86 -processorer til Apple -silicium . For at glide overgangen tilføjede Apple understøttelse af Universal 2 binært format. Dette tillader oprettelse af binærfiler, der kører indbygget på både 64-bit Intel og 64-bit Apple silicium (en AArch64- variant). Derudover introducerede Apple Rosetta 2 dynamisk binær oversættelse til x86 til Arm64 instruktionssæt, så brugerne kan køre programmer, der ikke har Universal binære varianter.

CP/M og DOS

Kombinerede binære filer i COM-stil til CP/M-80 og DOS

CP/M-80 , MP/M-80 , Concurrent CP/M , CP/M Plus og Personal CP/M-80 eksekverbare filer til Intel 8080 (og Z80 ) processorfamilier bruger den samme .COM -filtypenavn som DOS- kompatibel operativsystemer til Intel 8086 -binarier. I begge tilfælde indlæses programmer ved forskydning +100 timer og udføres ved at hoppe til den første byte i filen. Da opcoderne for de to processorfamilier ikke er kompatible, fører forsøg på at starte et program under det forkerte operativsystem til forkert og uforudsigelig adfærd.

For at undgå dette er der udviklet nogle metoder til at opbygge fedtbinarier, der både indeholder et CP/M-80 og et DOS-program, efter en indledende kode, der tolkes korrekt på begge platforme. Metoderne kombinerer enten to fuldt funktionelle programmer, der hver er bygget til deres tilsvarende miljø, eller tilføjer stubber, der får programmet til at forlade graciøst, hvis det startes på den forkerte processor. For at dette skal fungere, skal de første få instruktioner i .COM -filen være en gyldig kode for både 8086- og 8080 -processorer, hvilket ville få processorerne til at forgrene sig til forskellige steder i koden. Hjælpeprogrammerne i Simeon Crans emulator MyZ80 starter f.eks. Med opkodesekvensen EBh, 52h, EBh . En 8086 ser dette som et spring og læser sin næste instruktion fra offset +154h, hvorimod en 8080 eller kompatibel processor går lige igennem og læser sin næste instruktion fra +103h. En lignende sekvens anvendt til dette formål er EBh, 03h, C3h .

En anden metode til at forhindre, at et DOS-kompatibelt operativsystem fejlagtigt udfører .COM-programmer til CP/M-80 og MSX-DOS- maskiner, er at starte 8080-koden med C3h, 03h, 01h , som afkodes som en "RET" -instruktion af x86 -processorer og forlader derved yndefuldt programmet, mens det vil blive afkodet som "JP 103h" -instruktion af 8080 processorer og simpelthen springe til den næste instruktion i programmet.

Nogle CP/M-80 3.0 .COM-filer kan have et eller flere RSX- overlejringer knyttet til dem af GENCOM. I så fald starter de med et ekstra 256-byte header (en side ). For at angive dette er den første byte i headeren indstillet til magisk byte C9h , der både fungerer som en signatur, der identificerer denne type COM -fil til CP/M 3.0 -eksekverbar loader , samt en "RET" -instruktion for 8080 -kompatible processorer, der fører til en yndefuld exit, hvis filen udføres under ældre versioner af CP/M-80.

C9h er aldrig passende som den første byte i et program til enhver x86 -processor (den har forskellige betydninger for forskellige generationer, men er aldrig en meningsfuld første byte); den eksekverbare loader i nogle versioner af DOS afviser COM -filer, der starter med C9h , og undgår forkert betjening.

Kombinerede binære filer til CP/M-86 og DOS

CP/M-86 og DOS deler ikke en fælles filtypenavn til eksekverbare filer. Det er således normalt ikke muligt at forvirre eksekverbare filer. Imidlertid havde tidlige versioner af DOS så meget tilfælles med CP/M med hensyn til dets arkitektur, at nogle tidlige DOS -programmer blev udviklet til at dele binære filer, der indeholder eksekverbar kode. Et program, der var kendt for at gøre dette, var WordStar 3.2x , der brugte identiske overlay-filer i deres porte til CP/M-86 og MS-DOS , og brugte dynamisk opstillet kode til at tilpasse sig de forskellige opkaldskonventioner i disse operativsystemer under runtime .

Digital Research 's GSX til CP / M-86 og DOS deler også binære identiske 16-bit-drivere.

Kombinerede COM- og SYS -filer

DOS -enhedsdrivere starter med et filhoved, hvis første fire bytes er FFFFFFFFh efter konvention, selvom dette ikke er et krav. Dette rettes dynamisk op af operativsystemet, når driveren indlæses (typisk i DOS BIOS, når den udfører DEVICE -sætninger i CONFIG.SYS ). Da DOS ikke afviser filer med en .COM -udvidelse, der skal indlæses pr. ENHED, og ​​ikke tester for FFFFFFFFh, er det muligt at kombinere et COM -program og en enhedsdriver til den samme fil ved at placere en springinstruktion til indgangspunktet for integreret COM -program inden for de første fire bytes i filen (tre bytes er normalt tilstrækkelige). Hvis det integrerede program og enhedsdriversektionerne deler en fælles del af kode eller data, er det nødvendigt for koden at håndtere at blive indlæst offset +0100h som et .COM -stilprogram og +0000h som enhedsdriver. For delt kode indlæst med den "forkerte" forskydning, men ikke designet til at være positionsuafhængig , kræver dette en intern adresseoprettelse svarende til, hvad der ellers allerede ville have været udført af en flytende læsser , bortset fra at den i dette tilfælde har skal udføres af selve det indlæste program; dette ligner situationen med selvflyttende drivere, men med programmet, der allerede er indlæst på målstedet af operativsystemets loader.

Crash-beskyttede systemfiler

Under DOS har nogle filer efter konvention konventionelle filudvidelser, der ikke afspejler deres faktiske filtype. For eksempel er COUNTRY.SYS ikke en DOS -enhedsdriver , men en binær NLS -databasefil til brug med CONFIG.SYS COUNTRY -direktivet og NLSFUNC -driveren. PC DOS og DR-DOS systemfiler IBMBIO.COM og IBMDOS.COM er specielle binære billeder, ikke programmer i COM-stil. Hvis du prøver at indlæse COUNTRY.SYS med en DEVICE -sætning eller udfører IBMBIO.COM eller IBMDOS.COM ved kommandoprompten, vil der opstå uforudsigelige resultater.

Det er undertiden muligt at undgå dette ved at anvende teknikker, der ligner dem, der er beskrevet ovenfor. For eksempel indeholder DR-DOS 7.02 og nyere en sikkerhedsfunktion udviklet af Matthias R. Paul: Hvis disse filer kaldes upassende, vil små indlejrede stubbe bare vise nogle filversionsoplysninger og forlade yndefuldt.

En lignende beskyttelsesfunktion var 8080-instruktionen C7h ("RST 0") i starten af Z-System- sprogoverlejringsfiler, hvilket ville resultere i en varm start (i stedet for et nedbrud) under CP/M-80, hvis den blev indlæst uhensigtsmæssigt.

På en lignende måde omfatter mange (binære) filformater efter konvention en 1Ah byte ( ASCII ^Z ) nær begyndelsen af ​​filen. Dette kontroltegn vil blive fortolket som "blød" end-of-file (EOF) markør, når en fil åbnes i ikke-binær tilstand og dermed under mange operativsystemer (herunder RT-11 , VMS , CP/M, DOS og Windows) forhindrer det, at "binært skrald" vises, når en fil ved et uheld indtastes på konsollen.

Linux

FatELF: Universelle binære filer til Linux

Image
FatELF logo

FatELF er en fed binær implementering til Linux og andre Unix-lignende operativsystemer. Teknisk set er en FatELF -binær en sammenkædning af ELF -binarier med nogle metadata, der angiver hvilken binær, der skal bruges til hvilken arkitektur. Derudover til CPU-arkitektur abstraktion ( byte orden , ord størrelse , CPU instruktionssæt, etc.), der er den fordel, at binære filer med understøttelse af flere kerne Abis og versioner.

FatELF har flere brugstilfælde ifølge udviklere:

  • Distributioner behøver ikke længere at have separate downloads til forskellige platforme.
  • Adskilte /lib , /lib32 og /lib64 træer kræves ikke længere i OS -biblioteksstrukturen .
  • De korrekte binære og biblioteker vælges centralt af systemet i stedet for shell -scripts .
  • Hvis ELF ABI ændres en dag, kan gamle brugere stadig understøttes.
  • Distribution af webbrowser plug -ins, der fungerer ud af boksen med flere platforme.
  • Distribution af en applikationsfil, der fungerer på tværs af Linux- og BSD OS -varianter, uden et platformskompatibilitetslag på dem.
  • Én harddiskpartition kan startes på forskellige maskiner med forskellige CPU -arkitekturer til udvikling og eksperimentering. Samme rodfilsystem, anden kerne og CPU -arkitektur.
  • Applikationer leveret af netværksdeling eller USB -sticks fungerer på flere systemer. Dette er også nyttigt til at oprette bærbare applikationer og også cloud computing -billeder til heterogene systemer.

Et proof-of-concept Ubuntu 9.04- billede er tilgængeligt. Den 25. april 2020 er FatELF ikke blevet integreret i mainline Linux -kernen.

Windows

Fatpack

Selvom det Portable Executable -format, der bruges af Windows, ikke tillader tildeling af kode til platforme, er det stadig muligt at lave et loader -program, der afsendes baseret på arkitektur. Dette skyldes, at desktopversioner af Windows på ARM understøtter 32-bit x86- emulering, hvilket gør det til et nyttigt "universelt" maskinkodemål. Fatpack er en loader, der demonstrerer konceptet: det indeholder et 32-bit x86-program, der forsøger at køre eksekverbare filer pakket ind i sine ressourceafsnit en efter en.

Lignende begreber

Følgende fremgangsmåder ligner fedtbinarier, idet flere versioner af maskinkode til samme formål findes i den samme fil.

Fede genstande

GCC og LLVM har ikke et fedt binært format, men de har fede objektfiler til optimering af link-time (LTO). Da LTO indebærer at forsinke kompilationen til link-tid, skal objektfilerne gemme den mellemliggende repræsentation (IR), men på den anden side kan maskinkode også blive gemt (for hastighed eller kompatibilitet). Et LTO -objekt, der indeholder både IR og maskinkode, er kendt som et fedtobjekt .

Funktion multi-versioning

Selv i et program eller bibliotek beregnet til den samme instruktionssætarkitektur , kan en programmør ønske at gøre brug af nogle nyere instruktionssætudvidelser, samtidig med at den bevarer kompatibiliteten med en ældre CPU. Dette kan opnås med funktion multi-versioning (FMV): versioner af den samme funktion skrives ind i programmet, og et stykke kode afgør, hvilken der skal bruges ved at registrere CPU'ens kapacitet (f.eks. Via CPUID ). Intel C ++ Compiler , GNU Compiler Collection og LLVM har alle mulighed for automatisk at generere funktioner i flere versioner. Dette er en form for dynamisk udsendelse uden semantiske effekter.

Mange matematiske biblioteker har håndskrevne samlingsrutiner, der automatisk vælges i henhold til CPU-kapacitet. Eksempler inkluderer glibc , Intel MKL og OpenBLAS . Derudover understøtter bibliotekslæsseren i glibc indlæsning fra alternative stier til specifikke CPU -funktioner.

En lignende, men byte-niveau granulær tilgang, der oprindeligt var udtænkt af Matthias R. Paul og Axel C. Frinke, er at lade en lille selvkasserende, afslappende og flytende læsser indlejret i den eksekverbare fil sammen med et vilkårligt antal alternative binære kodestykker betinget bygge et størrelse- eller hastighedsoptimeret runtime-billede af et program eller en driver, der er nødvendig for at udføre (eller ikke udføre) en bestemt funktion i et bestemt målmiljø ved indlæsningstid gennem en form for dynamisk dødkodeeliminering (DDCE).

Se også

Noter

Referencer

Yderligere læsning