Mõned aastad tagasi kirjoitti Fabrice Bellard jslinuxist — PC simulaator, mis on kirjutatud JavaScriptis. Pärast seda on veel vähemalt Virtual x86. Kuid kõik need, kui ma ei eksi, olid tõlgendajad, samas kui palju varem Fabrice Bellardi kirjutatud Qemu, ja ilmselt iga tänapäevane emulaator, kasutab JIT-kompileerimist külalisprotsessi koodist hosti süsteemi koodiks. Minu arvates oli õige aeg rakendada tagurpidi ülesanne, mida veebibrauserid lahendavad: JIT-kompileerimine masinkoodist JavaScripti, mille jaoks tundus kõige mõistlikum portida Qemu. Tundub, et miks just Qemu, on olemas ka lihtsamaid ja kasutajasõbralikumaid emulaatoreid — näiteks VirtualBox, mille paigaldad ja see töötab. Aga Qemu-l on mitmeid huvitavaid omadusi

• avatud lähtekood
• võimalus töötada ilma tuumadraiverita
• võimalus töötada tõlgendajarežiimis
• toetab suurt hulka nii host- kui ka külalisarhitektuure

Kolmanda punkti osas võin nüüd selgitada, et tegelikult tõlgendatakse TCI režiimis mitte külaliste masininstruktsioone, vaid neist saadud bytecode'i, aga see ei muuda asja — et Qemu uuel arhitektuuril kokku panna ja käivitada, on õnne korral piisav C kompilaator — koodigeneraatori kirjutamine võib jääda hilisemaks.

Ja nii, pärast kaht aastat aeglast kohandamist Qemu lähtekoodiga vabamas ajas, ilmus töötav prototüüp, milles on juba võimalik näiteks käivitada Kolibri OS-i.

Mis on Emscripten

Meie ajal on ilmunud palju kompilaatoritest, mille lõpptulemus on JavaScript. Mõned, nagu TypeScript, mõeldi algselt parimaks viisiks veebis kirjutamiseks. Samal ajal on Emscripten viis võtta olemasolev C või C++ kood ja kompileerida see vormi, mis on brauserile arusaadav. On sellel leheküljel kogutud mitmeid tuntud programmide portte: siin, näiteks võib vaadata PyPy-d — muide, nagu väidetakse, on neil juba JIT. Tegelikult ei saa iga programmi lihtsalt kompileerida ja brauseris käivitada — on mitmeid eriti, millega tuleb leppida, nagu ütleb see leht "Emscripten saab kasutada peaaegu igasuguste portable C/C++ koodi JavaScriptiks. See tähendab, et on olemas rida operatsioone, mis on standardi järgi määratlemata käitumine, kuid tavaliselt töötavad x86-l — näiteks, korraldamata juurdepääs muutujaile, mis mõnel arhitektuuril on täiesti keelatud. Ühesõnaga, Qemu on platvormidevaheline programm ja, mida sooviksin uskuda, ei sisalda see palju määratlemata käitumist — võta ja kompileeri, siis veidi vaeva JIT-i ning valmis! Kuid mitte nii kiiresti…

Esimene katse

Üldiselt ei ole ma esimene, kellele tuli mõte Qemu JavaScripti portida. ReactOS foorumis esitati küsimus, kas see on võimalik teha Emscripteni abil. Varem ilmusid kuulujutud, et selle tegi isiklikult Fabrice Bellard, kuid jutt käis jslinuxist, mis, niipalju kui mina tean, on katse käsitsi saavutada JS-is piisavat jõudlust ja on kirjutatud nullist. Hiljem kirjutati Virtual x86 — sellele olid välja pandud mitteobfuseeritud lähtekoodid ning väidetavalt võimaldas suurem "realistlikkus" emulatsioonis kasutada SeaBIOS-i firmware’ina. Lisaks oli vähemalt üks katse portida Qemu Emscripteni abil — seda üritas teha socketpair, kuid arendamine, niipalju kui ma aru sain, jäeti seisma.

Nii et, näiliselt on siin lähtekoodid, siin on Emscripten — võta ja kompileeri. Kuid on olemas ka teegid, millest Qemu sõltub, ning teegid, millest need teegid sõltuvad jne, kusjuures üheks neist on libffi, millest sõltub glib. Internetis levisid kuulujutud, et Emscripteni laiendite suures raamatukogus on see olemas, kuid uskusin pigem vaevalt: esiteks, uut kompilaatorit selle jaoks ei eksisteerinud, teiseks, see on liiga madala taseme raamatukogu, et lihtsalt võtta ja JS-ks kompileerida. Asi ei seisne ainult assembleri sisselülitustes — tõenäoliselt, kui pingutada, siis mõnele n-ö calling convention'ile on võimalik ka ilma nendeta vajalikud argumendid stack'i tekitada ja funktsiooni kutsuda. Ainult Emscripten on keeruline asi: selleks, et genereeritud kood näeks välja harjunud JS-mootori optimeerijatele, kasutatakse mitmeid trikke. Eriti nn relooping — koodigeneraator püüab saadud LLVM IR-i põhjal, kasutades teatud abstraktseid hüppeinstruktsioone, rekonstrueerida usutavaid if-e, tsüklit jne. Ja kuidas edastatakse argumente funktsiooni? Loomulikult, nagu JS-funktsioonide argumendid, see tähendab, et võimaluse korral mitte läbi stack'i.

Alguses oli mõte lihtsalt kirjutada libffi asendus JS-is ja lasta läbi tavalised testid, kuid lõppkokkuvõttes segasin end segadusse, kuidas muuta oma header-failid, et need töötaks olemasoleva koodiga — mis sa teed, nagu öeldakse, "Kas probleemid on nii keerulised või oleme meie nii rumalad". Olin sunnitud portima libffi veel ühele arhitektuurile, kui nii võib öelda — õnneks on Emscriptenis olemas nii makrosid inline assembleri jaoks (JavaScriptis, jah — mis arhitektuur, sellel ka assembler) kui ka võimalus käivitada jooksvalt genereeritud koodi. Lühidalt, pärast mõningaid heitlemisi platformi sõltuvate libffi fragmentidega, sain mingit kompileeritavat koodi ja käivitasin selle esimesel ettejuhtuval testil. Minu üllatuseks läbis test edukalt. Olles oma geeniusest üllatunud — ei, polnud nalja, töötas esimesel katsel — vaatasin ikka veel, mitte uskudes oma silmi, uuesti saadud koodi, et hinnata, kuhu edasi kaevuda. Siin sain uuesti üllatuse — ainus, mida mu funktsioon tegi ffi_call — oli edastada eduka üleskutsumise teade. Üleskutset endaga ei toimunud. Nii saatsin oma esimese pull request'i, mis parandas arusaadavat iga olümpia osalejale viga testis — reaalarve ei tohiks võrrelda nagu a == b ja isegi nagu a - b < EPS — tuleb veel moodul unustada, muidu 0 osutub väga isegi 1/3… Ühesõnaga, ma sain mingisuguse libffi teegi, mis läbib kõige lihtsamad testid ja millega compileeritakse glib — otsustasin, et hiljem kirjutan juurde. Kui ette vaadata, siis selgus, et kompilaator ei lisanud isegi lõplikku koodi libffi funktsioonile.

Aga nagu ma juba ütlesin, on mõned piirangud ja mitmekesisest määramatust käitumisest peitis end ühtlaselt ebameeldiv joon — JavaScript ei toeta disaini kohaselt samaaegset mälukasutust. Põhimõtteliselt võib seda isegi nimetada mõistlikuks ideeks, kuid mitte koodi portimise jaoks, mille arhitektuur tugineb C keele lõimedele. Üldiselt katsetatakse Firefoxis jagatud töötajate toetamisega ning pthreadi rakendus on Emscriptenis olemas, kuid ma ei tahtnud sellest sõltuda. Pidi vaikselt välja kaevama samaaegsuse Qemu koodist — see tähendab otsima, kus lõime käivitatakse, liigutama selle lõime töö keera eraldi funktsiooni ning järjestikku kutsuma sellised funktsioonid põhiloopist.

Teine katse

Mingil hetkel sai selgeks, et asi ei edene, ja et süsteemitunne on vajalik, et koodis üleliigseid lahendusi mitte rakendada. Tulemus: tuleb kuidagi süstemaatiliselt korraldada ämbrite lisamise protsess. Seetõttu võeti toona uusim versioon 2.4.1 (mitte 2.5.0, sest kes teab, võib-olla seal on veel mõned uue versiooni defektid, ning mul on enda defektidest täiesti piisavalt), ja esimese asjana kirjutati ohutult ümber thread-posix.c. Noh, see tähendab, et ohutult: kui keegi üritas teostada tegevust, mis viib lukustumiseni, kutsuti kohe välja funktsioon abort() — muidugi ei lahendanud see kohe kõiki probleeme, kuid vähemalt on see kuidagi meeldivam, kui andmete järjepidevust vaikides rikkuda.

Üldiselt aitab Emscripteni koodi portimisel väga palju valikud -s ASSERTIONS=1 -s SAFE_HEAP=1 — need tuvastavad teatud tüüpi määramatut käitumist, näiteks mittejoondatud aadresside juurde pääsemise (mis ei ole absoluutselt kooskõlas kirjutatud massiivide koodiga nagu HEAP32[addr >> 2] = 1) või vale arvu argumentidega funktsiooni kutsumise.

Üks asi, millest tasub rääkida, on joondamisvigade probleem. Nagu ma juba ütlesin, Qemu-l on "degeneratiivne" tõlgendav TCI (tiny code interpreter) koodigeneratsiooni taga ning et Qemu uue arhitektuuri jaoks üles ehitada ja käivitada, piisab, kui on olemas C-kood kompilaator. Märksõnad "kui on vedanud". Minul ei olnud vedamist ja selgus, et TCI kasutab oma bytecode'i tõlgendamisel mittejoondatud juurdejuurde. See tähendab, et igasuguste ARM'i ja teiste arhitektuuride puhul, kus on vaja joondatud juurdejuurde, Qemu kompileeritakse, kuna neile on olemas normaalne TCG tagakood, mis genereerib natiivset koodi, kuid kas TCI nendel töötab — see on veel küsimus. Siiski, nagu selgus, oli TCI dokumentatsioonis midagi sellist selgelt mainitud. Lõppkokkuvõttes lisati koodi mittejoondatud lugemise funktsioonid, mis avastati Qemu's muust osast.

Mälu purunemine

Lõppkokkuvõttes parandati TCI mittejoondatud juurdejuur ja tehti peamine tsükkel, mis järjestikuste kutsete kaudu töötas CPU, RCU ja paar väikest asja. Ja nüüd, käivitades Qemu valikuga -d exec,in_asm,out_asm, mis tähistab, et tuleb öelda, milliseid koodiblokke täidetakse, ja samuti, tõlkehetkel kirjutada, mis oli külalistarkvara kood ja mis hostitarkvara kood on (antud juhul, bytecode). See käivitub, teeb paar tõlkeplokki, kirjutab minu jätatud silumis teadete, et RCU hakkab tööle ja… kukub abort() funktsiooni sisse. free()Funktsiooni "kaevamise" teel free() õnnestus välja selgitada, et mälu bloki päises, mis asub kaheksa bait'i ulatuses eraldatud mälu ees, leidus block'i suuruse või nende laadse info asemel prügi.

Kuhja hävitamine — kui armas... Sellises olukorras on kasulik vahend — (kui võimalik) koguda samadest lähtefailidest natiivne binaarfail ja lasta see Valgrindis läbi. Mõne aja pärast oli binaarfail valmis. Käivitan samade parameetritega — kukub jälle initsialiseerimisel, olles jõudnud tegelikult teostuseni. Loomulikult on see ebameeldiv — ilmselt ei olnud lähtefailid siiski täpselt samad, mis pole üllatav, kuna configure leidis mõned teised parameetrid, kuid mul on ju Valgrind — kõigepealt fikseerin selle vea ja seejärel, kui mul vedas, ilmub ka algne. Käivitan kõik sama Valgrindis... Kuu-uu, ahh, see käivitub, möödub initsialiseerimisest normaalselt ja liigub edasi, mööda algsest veast ilma ainsa mäluaadressi vigade hoiatuseta, rääkimata kukkumistest. Selliseks eluks ei olnud mind ette valmistatud — kukkuv programm lõpetab kukkumise Valgrindis käivitades. Mis see oli — mõistatus. Minu hüpotees on, et kuna praeguse käsu ümbruses pärast kukkumist initsialiseerimisel näitas gdb tööd. memset-ga kehtiva näitajaga, kasutades kas mmx, või xmm registreid, siis võis see olla mingi joondusviga, kuigi siiski on raske uskuda.

Okei, Valgrind siin ei näi abiks olevat. Ja siin hakkas see kõige ebameeldivam osa — kõik nagu käivitub, aga kukub kokku täiesti arusaamatutel põhjustel sündmuse tõttu, mis võis juhtuda miljoneid käske tagasi. Pikalt ei olnud isegi aru, kuidas läheneda. Lõpuks tuli ikkagi istuda ja debugeerida. Pealkirja sedel, millega see oli ümber kirjutatud, näitas, et see ei näe välja nagu arv, vaid pigem mingid binaarsed andmed. Ja, oh ime, see binaarstring leiti BIOSi failist — seega sai nüüd küllalt kindlalt öelda, et see oli ülekoormus, ja isegi aru saada, mis sinna puhvri kirjutati. Edasi läks nii — Emscriptenis, õnneks, aadressiruumi randomiseerimist pole, ka auke ei ole, seega on võimalik kirjutada kuskil koodi keskel andmete väljundit näidates eelmisest käivitamisest, vaadata andmeid, vaadata näidikut ja, kui see pole muutunud, saada mõtteainet. Tõsi, iga muudatuse järel kulub linkimisele paar minutit, aga mis sa teed. Tulemuseks leiti konkreetne rida, mis kopeeris BIOSi ajutisest puhvrist külastaja mällu — ja tõepoolest, puhvris ei olnud piisavalt ruumi. Selle kummalise puhveraadressi allika otsimine viis funktsiooni qemu_anon_ram_alloc failis oslib-posix.c — loogika oli selline: mõnikord võib olla kasulik joondada aadress huge page'iga, mille suurus on 2 Mb, selleks palume mmap esialgu veidi rohkem ja seejärel anname üleliigse tagasi kasutades munmap. Ja kui sellist joondamist ei ole vaja, siis määrame 2 Mb asemel tulemuse getpagesize() — mmap siiski annab joondatud aadressi... Nii et Emscriptenis mmap lihtsalt kutsub välja malloc, ja see ei jaga loomulikult lehekülge. Ühesõnaga, viga, mis mind paar kuud häiris, likvideeriti muutusega kaks ridadel.

Funktsioonide kutsumise eripära

Ja nüüd juba protsessor midagi arvutab, Qemu ei kaku, aga ekraan ei lülitu sisse ja protsessor läheb kiiresti silmusesse, nagu nähtub väljundist -d exec,in_asm,out_asm. Ilmnes teooria: taimeri katkestusi ei tule (või tõepoolest kõiki katkestusi). Ja tõepoolest, kui eemaldada katkestused natiivse kompileerimise variandist, mis kummalisel kombel töötas, saab sarnase pildi. Kuid saladus ei olnud üldse selles: võrdlemine jälgimistest, mis saadeti ülaltoodud valikuga, näitas, et täitmise trajektoorid lahknevad väga varakult. Siinkohal tuleb öelda, et salvestamise võrdlemine käivitusprogrammiga emrun debugimisväljastusega natiivse kompileerimise väljastusega ei ole sugugi mehaaniline protsess. Ma ei tea täpselt, kuidas veebibrauseris käivitatud programm on ühendatud emrun, kuid mõned read väljundis on paigutatud teineteisega segamini, seega erinevus diffis ei ole veel põhjus arvata, et trajektoorid on lahku läinud. Üldiselt sai selgeks, et juhiste järgi ljmpl toimub üleminek erinevatele aadressidele ja ka bytecode genereeritakse põhimõtteliselt erinevalt: ühes on juhis C funktsiooni abifunktsiooni kutsumiseks, teises - ei ole. Pärast juhist otsimist ja koodi uurimist, mis neid juhiseid tõlgib, sai selgeks, et esiteks viidi sellele registreerimisega cr0 seotud abifunktsiooni kaudu - mis tõi protsessori kaitstud režiimi, ja teiseks, et js-versioon ei jõudnud kaitstud režiimi. Asi on selles, et Emscripteni veel üks omadus on vastumeelsus taluda koodi nagu käskluse implementatsioon call TCIs, mis viib iga funktsiooni näitaja tüüpi long long f(int arg0, .. int arg9) — funktsioone tuleb kutsuda õige argumendi arvuga. Kui seda reeglit rikutakse, kukub programm sõltuvalt silumiseseadetest kas alla (mis on hea) või kutsub üles täiesti vale funktsiooni (mida on kurvalt keeruline siluda). On veel kolmas võimalus - lubada ümbriste genereerimist, mis lisavad/eemaldavad argumente, kuid kokkuvõttes võtavad need ümbrised väga palju ruumi, arvestades, et mulle on tegelikult vaja vaid natuke üle saja ümbrise. Juba see on üsna kurb, kuid osutus tõsisem probleem: genereeritud koodi funktsioonide ümbristes muudetud argumendid konverteeriti, kuid genereeritud argumentidega funktsiooni kohati ei kutsutud — täpselt nagu minu libffi teostuses. See tähendab, et mõned abifunktsioonid lihtsalt ei töötanud.

Õnneks on Qemu-l masina loetavaid abimeeste loendeid pealkirjafaili kujul, nagu

DEF_HELPER_0(lock, void)
DEF_HELPER_0(unlock, void)
DEF_HELPER_3(write_eflags, void, env, tl, i32)

Neid kasutatakse üsna lõbusalt: kõigepealt üledefineeritakse makrod kõige kaootilisemal viisil DEF_HELPER_n, siis lisatakse helper.h. Kuni selle hetkeni, et makro avaldub struktuuri initsialiseerijas ja koma, seejärel määratletakse massiiv, mille asemel on #include <helper.h> Lõpuks tuli võimalus proovida raamatukogu pyparsing, ja kirjutati skript, mis genereerib täpselt need mähised ja ainult nende funktsioonide jaoks, mis on vajalikud.

Ja nii, pärast seda näib protsessor töötavat. Näib, et ekraan ei initsialiseerunud, kuigi natiivses kogus suudeti käivitada memtest86+. Siin tuleks täpsustada, et Qemu blokeerimise seadmete kood on kirjutatud korutine; Emscriptenil on oma üsna keeruline rakendus, kuid seda tuli veel toetada Qemu koodis, andes võimaluse protsessorit juba praegu testida: Qemu toetab valikuid -kernel, -initrd, -append, millega saab laadida Linuxi või näiteks memtest86+, kasutamata tegelikult blokeerimise seadmeid. Aga siin oli probleem: natiivses kogus oli võimalik näha Linuxi kernelit konsoolil valiku -nographic, aga brauserist ei tulnud mingit väljundit terminali, kust see käivitati emrun, ei tulnud. Tundub, et protsessor ei tööta või on probleem graafika väljundis. Ja siis tuli mul meelde natuke oodata. Selgus, et "protsessor ei maga, vaid lihtsalt vilgub aeglaselt", ja umbes viie minuti pärast viskas tuum konsoolile rida teateid ja jätkas edasist hangumist. Selgeks sai, et protsessor toimib üldiselt, ja tuleb otsida SDL2 koodi. Kahjuks ei oska ma seda raamatukogu kasutada, nii et kohati tuli tegutseda õnne kõige põhjalikumal viisil. Ühes hetkes vilkus ekraanil rida parallel0 sinisel taustal, mis mõjus teatud mõtetena. Lõpuks osutus probleemiks, et Qemu avab mitmeid virtuaalseid aknaid ühe füüsilise akna sees, mille vahel saab vahetada Ctrl-Alt-n: natiivses koguses töötab see, Emscriptenis – mitte. Pärast mittevajalike akende eemaldamist valikute abil -monitor none -parallel none -serial none ja sundides kogu ekraani iga kaadriga ümber joonistama, toimus kõik järsku.

Korutine

Nii, brauseri emulatsioon töötab, kuid midagi huvitavat ühe ketta pealt ei saa käivitada, kuna ei ole plokk sisend-väljundit — vajalik on toetada koruutine. Qemu-s on juba mõned koruutine tagaplaanid olemas, kuid JavaScripti ja Emscripteni koodigeneraatori eripära tõttu ei saa lihtsalt võtta ja hakata kuhjama stekke. Tundub, et "kõik on kadunud, kips võetakse maha", kuid Emscripteni arendajad on juba kõigest hoolitsenud. Selle rakendamine on üsna märkamatult: mis oleks, kui nimetaksime kahtlaseks funktsiooni väljakutset nagu emscripten_sleep ja mõned teised, mis kasutavad Asyncify mehhanismi, samuti väljakutsed.Pointeri kaudu ja väljakutsed igasuguste funktsioonide puhul, kus allpool stekis võib esineda üks kahest eelnevast olukorrast. Ja nüüd eraldame iga kahtlase väljakutse korral asünkroonse konteksti, ning kohe pärast väljakutset kontrollime, kas toimus asünkroonne välja kutse, ja kui toimus, salvestame kõik lokaalsed muutujad sellesse asünkroonsesse konteksti, määrame, millise funktsiooni juurde tuleb edastada juhtimine, kui tuleb jätkata täitmist, ning lahkume praegusest funktsioonist. Siin on ruumi uurida efekti tükeldamist — vajaduseks koodi jätkamiseks pärast asünkroonsest väljakutsest tagasiminekut genereerib kompilaator "lõike" funktsiooni, mis algavad pärast kahtlast väljakutset — nii: kui on n kahtlast väljakutset, siis funktsioon lõhustatakse kuskil n/2 võrra — ja see on veel, kui mitte arvestada, et algsele funktsioonile tuleb pärast iga potentsiaalselt asünkroonset väljakutset lisada osa lokaalsest muutujast. Hiljem tuli isegi kirjutada lihtne skript Pythoni keeles, mis antud kogumi eriti tükeldatud funktsioonide põhjal, mis eeldatavalt "ei luba asünkroonsust enda kaudu" (s.o. nendes ei toimu steki kerimist ja kõik see, mida ma just kirjeldasin), osutab, milliseid väljakutseid läbi indikaatorite mõnedes funktsioonides tuleb kompilaatoril ignoreerida, et neid funktsioone ei käsitletaks nagu asünkroonseid. Sest 60 MB JS-failid on juba ilmselgelt üle mõistuse — olgu vähemalt 30. Kuigi, kord seadsin üles kogumisk skripti ja juhuslikult viskasin välja linkimise valikud, mille seas oli ka -O3. Käivitan genereeritud koodi ja Chromium tarbib mälu ning kukub kokku. Hiljem juhuslikult vaatasin, mida ta proovis laadida... Noh, mida ma oskan öelda, ma jääks ka seisma, kui mind palutaks põhjalikult uurida ja optimeerida JavaScripti 500+ MB ulatuses.

Kahjuks ei olnud Asyncify toe teegi koodis kontrollid eriti ühilduvad longjmp-dega, mida kasutatakse virtuaalse protsessori koodis, kuid pärast väikest puhasti, mis need kontrollid välja lülitas ja sunniviisiliselt taastada kontekstid nagu kõik oleks hästi, kood töötas. Siis hakkas midagi kummalist juhtuma: mõnikord aktiveerusid sünkroniseerimise koodi kontrollid - need, mis lõpetavad koodi, kui selle täitmise loogika järgi peaks see blokeeruma - keegi üritas haarata juba haaratud mutexi. Õnneks ei olnud see loogiline probleem seeriakoodis - lihtsalt kasutasin Emscripteni pakkumist, milleks on peamine tsükkel, kuid mõnikord asünkroonne kutsumine voldis mälu täielikult lahti ja sel hetkel aktiveerus setTimeout peamisest tsüklist - seega sattus kood peamise tsükli iteratsioonile, ilma et oleks eelmisest iteratsioonist väljunud. Kirjutasin ümber lõpmisse tsüklisse ja emscripten_sleep, ja probleemid mutexidega lõppesid. Kood muutus isegi loogilisemaks - sest põhimõtteliselt ei ole mul mingit koodi, mis valmistab ette uue animatsiooni kaadri - lihtsalt protsessor arvutab midagi ja ekraan värskendatakse perioodiliselt. Kuid probleemid sellega ei lõppenud: mõnikord lõpetas Qemu täitmise lihtsalt vaikselt, ilma igasuguste erandite ja vigadeta. Sel hetkel ei viitsinud ma sellega tegeleda, kuid edasi vaadates ütlen, et probleem oli järgmine: koroutine kood ei kasutanud tegelikult setTimeout (noh või vähemalt ei kasutanud nii sageli, kui võiks arvata): funktsioon emscripten_yield lihtsalt seab asünkroonse kutsumise lippu. Kogu asi on selles, et emscripten_coroutine_next ei ole asünkroonne funktsioon: sees ta kontrollib lippu, lähtestab selle ja edastab juhtimise sinna, kuhu see vajalik. See tähendab, et tema juures lõppeb mälu pööramine. Probleem oli selles, et „use-after-free“ tõttu, mis ilmnes koroutine pooled välja lülitamisel, kuna ma ei kopeerinud vajalikku koodireadet olemasolevast coroutine backendist, funktsioon qemu_in_coroutine tagastas true, kui tegelikult oleks pidanud tagastama false. See viis kutsumiseni emscripten_yield, mille ülemineku kohal, ei olnud emscripten_coroutine_next, virn ulatus kõige kõrgemale, kuid mingeid setTimeout, nagu ma juba ütlesin, ei olnud seadistatud.

JavaScripti koodigeneerimine

Ja siin on, lubatud "liha tagasi pööramine". Tegelikult ei ole. Loomulikult, kui käitada brauseris Qemu ja seal - Node.js, siis pärast koodigeneerimist Qemus saame kindlasti hoopis teistsuguse JavaScripti. Aga siiski, mingisugune tagasipööramine on olemas.

Esmalt natuke sellest, kuidas Qemu töötab. Palun vabandage mind kohe: ma ei ole Qemu professionaalne arendaja ja minu järeldused võivad olla kohati ekslikud. Nagu öeldakse, "üliõpilase arvamus ei pea kokku langema õpetaja, Peano aksioomide ja ühiskondliku mõistusega". Qemu-l on teatud hulk toetatud külgarhitektuure ja igaühe jaoks on kataloog, nagu target-i386. Koostamisel saab määrata mitme külgarhitektuuri toetuse, kuid tulemuseks on lihtsalt mitu binaarfaili. Kood külgarhitektuuri toetamiseks genereerib omakorda mõned Qemu sisemised toimingud, mille TCG (Tiny Code Generator) juba muundab hostiarhitektuuri masinkoodiks. Nagu väidetakse tcg kataloogis asuvas readme-failis, oli see algselt osa tavalise C-kompilaatori tööst, mida hiljem kohandati JIT-i jaoks. Seega, näiteks, sihtharhitektuur selle dokumendi terminites - ei ole enam külgharhitektuur, vaid hostiarhitektuur. Ühel hetkel ilmus veel üks komponent - Tiny Code Interpreter (TCI), mis peaks täitma koodi (peaaegu samu sisemisi toiminguid) ilma konkreetse hostiarhitektuuri koodigeneerijata. Tegelikult, nagu on öeldud tema dokumentatsioonis, ei pruugi see tõlgendaja alati töötada sama hästi kui JIT-koodigeneerija mitte ainult kvantitatiivselt kiiruselt, vaid ka kvalitatiivselt. Kuigi ma ei ole kindel, et tema kirjeldus on täielikult ajakohane.

Alguses üritasin luua täisväärtuslikku TCG tagavara, kuid segadusse sattusin kiiresti lähtekoodides ja mitte eriti selges baytkoodi käskude kirjelduses, seetõttu otsustasin TCI tõlgendajat ümber kirjutada. See andis koheselt mitmeid eeliseid:

• koodigeneerija rakendamisel sai vaadata mitte käskude kirjeldust, vaid tõlgendaja koodi
• Saab genereerida funktsioone mitte iga kohatud tõlkeploki jaoks, vaid näiteks alles pärast utsesandat 100. täitmist.
• Kui genereeritud koodis midagi muutub (mis näib olevat võimalik, arvestades funktsioone, mille nimedes on sõna patch), pean invalideerima genereeritud JS-koodi, kuid vähemalt on mul võimalus seda uuesti genereerida.

Kolmanda punkti osas ei ole ma kindel, et patchimine on võimalik pärast koodi esmakordset täitmist, kuid esimesed kaks punkti on piisavad.

Alguses genereeriti kood suurena switch-lausesse, mis viitas lähtestatud käsu byte'ile, kuid hiljem, meenutades artiklit Emscripteni kohta, genereeritava JS-i optimeerimist ja reloopingut, otsustasin genereerida inimeste jaoks arusaadavam kood, eriti kuna praktiliselt selgus, et ainus sissepääs tõlkeplokki on selle algus. Nii ka tehti, mõne aja pärast sai valmis koodigeneraator, mis genereeris koodi if-idega (kuigi ilma tsükliteta). Kuid häda on selles, et see kukkus, andes teada, et käsk osutus mingi vale pikkusega. Samal ajal oli see viimane käsk selle rekurssiooni tasemel. brcond. Hästi, lisan identse kontrolli selle käsu genereerimisse enne rekurssiooni kutsumist ja pärast seda ja... mitte ükski neist ei toiminud, kuid pärast assert'i switch'i järel kukkusid siiski. Lõpuks, analüüsides genereeritud koodi, sain aru, et pärast switch'i laaditakse viit praegusele käsule uuesti virnast ja seda tõenäoliselt katab genereeritud JavaScript-kood. Nii see oligi. Buffri suurendamine ühest megabaitist kümne peale ei aidanud midagi ja sai selgeks, et koodigeneraator jookseb ringi. Pidin kontrollima, et me ei ületaks hetke TB piire ja kui me ületasime, siis andma järgmise TB aadressi miinuse märgiga, et saaksime täitmist jätkata. Pealegi lahendab see probleemi, "milliseid genereeritud funktsioone invalidida, kui see tükk byte'ist muutus?" - tuleb invalidida ainult see funktsioon, mis vastab sellele tõlkeplokile. Muide, kuigi ma debugisin kõike Chromes (kuna kasutan Firefoxi ja mulle on mugavam eksperimenteerida eraldi brauseris), aitas Firefox mul parandada vastuolus asm.js standardiga, pärast mida töötas kood Chromes sujuvamalt.

Näidis genereeritud kood

Compiling 0x15b46d0:
CompiledTB[0x015b46d0] = function(stdlib, ffi, heap) {
"use asm";
var HEAP8 = new stdlib.Int8Array(heap);
var HEAP16 = new stdlib.Int16Array(heap);
var HEAP32 = new stdlib.Int32Array(heap);
var HEAPU8 = new stdlib.Uint8Array(heap);
var HEAPU16 = new stdlib.Uint16Array(heap);
var HEAPU32 = new stdlib.Uint32Array(heap);

var dynCall_iiiiiiiiiii = ffi.dynCall_iiiiiiiiiii;
var getTempRet0 = ffi.getTempRet0;
var badAlignment = ffi.badAlignment;
var _i64Add = ffi._i64Add;
var _i64Subtract = ffi._i64Subtract;
var Math_imul = ffi.Math_imul;
var _mul_unsigned_long_long = ffi._mul_unsigned_long_long;
var execute_if_compiled = ffi.execute_if_compiled;
var getThrew = ffi.getThrew;
var abort = ffi.abort;
var qemu_ld_ub = ffi.qemu_ld_ub;
var qemu_ld_leuw = ffi.qemu_ld_leuw;
var qemu_ld_leul = ffi.qemu_ld_leul;
var qemu_ld_beuw = ffi.qemu_ld_beuw;
var qemu_ld_beul = ffi.qemu_ld_beul;
var qemu_ld_beq = ffi.qemu_ld_beq;
var qemu_ld_leq = ffi.qemu_ld_leq;
var qemu_st_b = ffi.qemu_st_b;
var qemu_st_lew = ffi.qemu_st_lew;
var qemu_st_lel = ffi.qemu_st_lel;
var qemu_st_bew = ffi.qemu_st_bew;
var qemu_st_bel = ffi.qemu_st_bel;
var qemu_st_leq = ffi.qemu_st_leq;
var qemu_st_beq = ffi.qemu_st_beq;

function tb_fun(tb_ptr, env, sp_value, depth) {
  tb_ptr = tb_ptr|0;
  env = env|0;
  sp_value = sp_value|0;
  depth = depth|0;
  var u0 = 0, u1 = 0, u2 = 0, u3 = 0, result = 0;
  var r0 = 0, r1 = 0, r2 = 0, r3 = 0, r4 = 0, r5 = 0, r6 = 0, r7 = 0, r8 = 0, r9 = 0;
  var r10 = 0, r11 = 0, r12 = 0, r13 = 0, r14 = 0, r15 = 0, r16 = 0, r17 = 0, r18 = 0, r19 = 0;
  var r20 = 0, r21 = 0, r22 = 0, r23 = 0, r24 = 0, r25 = 0, r26 = 0, r27 = 0, r28 = 0, r29 = 0;
  var r30 = 0, r31 = 0, r41 = 0, r42 = 0, r43 = 0, r44 = 0;
    r14 = env|0;
    r15 = sp_value|0;
  START: do {
    r0 = HEAPU32[((r14 + (-4))|0) >> 2] | 0;
    r42 = 0;
    result = ((r0|0) != (r42|0))|0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445321] = r14;
    if(result|0) {
    HEAPU32[1445322] = r15;
    return 0x0345bf93|0;
    }
    r0 = HEAPU32[((r14 + (16))|0) >> 2] | 0;
    r42 = 8;
    r0 = ((r0|0) - (r42|0))|0;
    HEAPU32[(r14 + (16)) >> 2] = r0;
    r1 = 8;
    HEAPU32[(r14 + (44)) >> 2] = r1;
    r1 = r0|0;
    HEAPU32[(r14 + (40)) >> 2] = r1;
    r42 = 4;
    r0 = ((r0|0) + (r42|0))|0;
    r2 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    HEAPU32[1445321] = r14;
    HEAPU32[1445322] = r15;
    qemu_st_lel(env|0, r0|0, r2|0, 34, 22759218);
if(getThrew() | 0) abort();
    r0 = 3241038392;
    HEAPU32[1445307] = r0;
    r0 = qemu_ld_leul(env|0, r0|0, 34, 22759233)|0;
if(getThrew() | 0) abort();
    HEAPU32[(r14 + (24)) >> 2] = r0;
    r1 = HEAPU32[((r14 + (12))|0) >> 2] | 0;
    r2 = HEAPU32[((r14 + (40))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    qemu_st_lel(env|0, r2|0, r1|0, 34, 22759265);
if(getThrew() | 0) abort();
    r0 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[(r14 + (40)) >> 2] = r0;
    r1 = 24;
    HEAPU32[(r14 + (52)) >> 2] = r1;
    r42 = 0;
    result = ((r0|0) == (r42|0))|0;
    if(result|0) {
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    }
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    return execute_if_compiled(22759392|0, env|0, sp_value|0, depth|0) | 0;
    return execute_if_compiled(23164080|0, env|0, sp_value|0, depth|0) | 0;
    break;
  } while(1); abort(); return 0|0;
}
return {tb_fun: tb_fun};
}(window, CompilerFFI, Module.buffer)["tb_fun"]

Kokkuvõte

Nii et töö pole veel lõpule viidud, kuid selle pikaleveninud projekti viimistlemine on mind salaja väsitama hakanud. Seetõttu otsustasin praegu avaldada selle, mis on. Kood on kohati hirmutav, kuna tegemist on katsetusega ega ole ette teada, mida täpselt teha. Tõenäoliselt tuleks hiljem luua normaalsed aatomäärangud ühelt moodsamalt Qemu versioonilt. Praegu on olemas git-i haru, mis on formaadis blogi: iga „taseme“ kohta, mis on kuidagi läbitud, on lisatud ulatuslik kommentaar eesti keeles. Väärib märkimist, et see artikkel on suuresti tagasiviidud väljavõtte kirjeldus. git log.

Seda kõike saab proovida siin (ole ettevaatlik, liiklus).

Mis juba praegu töötab:

• Töötab virtuaalne x86 protsessor
• On töötav prototüüp JIT-koodigeneraatorist masinkoodist JavaScripti
• On ettevalmistus teiste 32-bitiste külalisarhitektuuride kogumiseks: saate praegu imetleda, kuidas Linux MIPS arhitektuuril, laadimise etapis, brauseris hangub.

Mis veel teha võiks

• Emulatsiooni kiiremaks muuta. Isegi JIT-režiimis töötab see näiliselt aeglasemalt kui Virtual x86 (aga potentsiaalselt on peal Qemu, millel on suur hulk emuleeritud riistvara ja arhitektuure).
• Luua normaalne liides — veebiarendaja olen ma, otsekui, nii-ehk-na, seetõttu muutsin seni vaid Emscripteni standardset liidest, nii nagu oskasin.
• Proovida käivitada keerukamaid Qemu funktsioone — võrk, VM migratsioon jne.
• UPD: Pean saatma Emscripteni oma ettevõe töötulemused ja vead ülesanne, nagu seda tegid varasemad Qemu ja teiste projektide porteerijad. Tänan neid võimaluse eest kasutada nende panust Emscriptenisse oma ülesande raames.

Allikas: habr.com