Il y a quelques années, Fabrice Bellard a écrit jslinux — un émulateur de PC écrit en JavaScript. Après cela, il y a eu au moins Virtual x86. Mais tous, autant que je sache, étaient des interpréteurs, tandis que Qemu, écrit beaucoup plus tôt par le même Fabrice Bellard, et probablement tout émulateur moderne de bonne réputation, utilise la compilation JIT du code invité en code de système hôte. Il m'a semblé qu'il était temps de réaliser la tâche inverse de celle que les navigateurs résolvent : la compilation JIT du code machine en JavaScript, pour laquelle il était logique de porter Qemu. On pourrait se demander pourquoi Qemu, il existe des émulateurs plus simples et conviviaux — comme VirtualBox, par exemple — qu'il suffit d'installer et de faire fonctionner. Mais Qemu a plusieurs caractéristiques intéressantes

• les sources ouvertes
• la possibilité de fonctionner sans pilote de noyau
• la possibilité de fonctionner en mode interpréteur
• le support d'un grand nombre d'architectures, tant hôtes qu'invitées

Pour le troisième point, je peux maintenant expliquer que, en réalité, en mode TCI, ce ne sont pas les instructions machine invitées qui sont interprétées, mais le bytecode qui en est dérivé, mais cela ne change rien à la situation — pour compiler et exécuter Qemu sur une nouvelle architecture, si tout va bien, un compilateur C suffit — la rédaction d'un générateur de code peut être remise à plus tard.

Et voilà, après deux ans de plongée tranquille dans les sources de Qemu, un prototype fonctionnel est apparu, sur lequel il est déjà possible de faire tourner, par exemple, Kolibri OS.

Qu'est-ce qu'Emscripten

De nos jours, de nombreux compilateurs existent dont le résultat final est du JavaScript. Certains, comme TypeScript, ont été conçus dès le départ comme un meilleur moyen d'écrire pour le web. En même temps, Emscripten est un moyen de prendre du code existant en C ou C++ et de le compiler dans un format compréhensible par le navigateur. Sur cette page de nombreux ports de programmes connus ont été réalisés : ici, par exemple, on peut jeter un œil à PyPy — d'ailleurs, il semble qu'ils aient déjà JIT. En réalité, il n'est pas possible de simplement compiler et exécuter n'importe quel programme dans un navigateur — il existe une série caractéristiques, avec laquelle il faut composer, cependant, comme le dit l'inscription sur cette même page "Emscripten peut être utilisé pour compiler presque n'importe quel portable Code C/C++ vers JavaScript. Cela signifie qu'il existe un certain nombre d'opérations qui sont un comportement indéfini selon la norme, mais qui fonctionnent généralement sur x86 — par exemple, l'accès non aligné aux variables, qui est complètement interdit sur certaines architectures. En général, Qemu est un programme multiplateforme et, espérons-le, ne contient pas trop de comportements indéfinis — prends et compile, puis un peu de manipulation avec JIT — et c'est prêt ! Mais ce n'est pas si simple...

Première tentative

En fait, je ne suis pas le premier à avoir eu l'idée de porter Qemu sur JavaScript. Sur le forum ReactOS, la question a été posée, est-ce possible avec Emscripten ? Plus tôt, des rumeurs circulaient selon lesquelles Fabrice Bellard l'avait fait personnellement, mais il s'agissait de jslinux, qui, autant que je sache, est en fait une tentative manuelle d'atteindre des performances suffisantes sur JS, et a été écrit à partir de zéro. Plus tard, Virtual x86 a été écrit — ses sources non obfusquées ont été publiées, et il a été affirmé qu'une plus grande "réalisme" d'émulation permettait d'utiliser SeaBIOS comme firmware. De plus, il y a eu au moins une tentative de porter Qemu avec Emscripten — cela a été tenté par socketpair, mais le développement, autant que j'ai compris, a été gelé.

Ainsi, on pourrait penser que voilà les sources, voilà Emscripten — prends et compile. Mais il y a aussi des bibliothèques dont Qemu dépend, et des bibliothèques dont ces bibliothèques dépendent, etc., et l'une d'elles est — libffi, dont lequel dépend glib. Sur Internet, il y avait des rumeurs selon lesquelles une grande collection de ports de bibliothèques pour Emscripten la contenait, mais il était difficile d'y croire : d'une part, elle ne se compilait pas avec le nouveau compilateur, et d'autre part, c'est une bibliothèque trop bas niveau pour simplement être compilée en JS. Ce n'est même pas seulement une question d'instructions assembleur — probablement, si on cherche à torturer un peu le système, pour certaines conventions d'appel, on peut former les arguments nécessaires sur la pile sans elles et appeler la fonction. Mais Emscripten est une chose délicate : pour que le code généré ait l'air familier pour l'optimiseur du moteur JS du navigateur, quelques trucs sont utilisés. En particulier, ce qu'on appelle le relooping — le générateur de code, à partir de l'IR LLVM reçu, essaie de recréer des if plausibles, des boucles, etc. Et les arguments de la fonction, comment sont-ils passés ? Évidemment, comme les arguments des fonctions JS, c'est-à-dire autant que possible, pas par la pile.

Au départ, j'avais l'idée d'écrire simplement un remplacement de libffi en JS et de faire tourner les tests standards, mais en fin de compte, je me suis embrouillé sur la façon de créer mes fichiers d'en-tête pour qu'ils fonctionnent avec le code existant — que voulez-vous, comme on dit, "Soit les tâches sont si complexes, soit nous sommes si stupides". J'ai donc dû porter libffi sur une autre architecture, si l'on peut dire — heureusement, dans Emscripten, il y a des macros pour l'assembly inline (en JavaScript, oui — quelle architecture, quel assembleur), ainsi que la possibilité d'exécuter le code généré à la volée. En somme, après avoir passé quelque temps avec les fragments dépendants de la plateforme de libffi, j'ai obtenu un code compilable et l'ai fait passer au premier test venu. À ma grande surprise, le test a été réussi. Étonné par ma génie — pas une blague, ça a fonctionné du premier coup — je, ne croyant toujours pas mes yeux, suis allé vérifier à nouveau le code obtenu, évaluer où approfondir mes recherches. Là, j'ai de nouveau été surpris — la seule chose que ma fonction faisait ffi_call — c'était rapporter un appel réussi. Il n'y avait pas eu d'appel. Ainsi, j'ai soumis ma première demande de tirage, corrigeant une erreur évidente pour tout olympien dans le test — les nombres à virgule flottante ne doivent pas être comparés comme a == b et même comme a - b < EPS — il ne faut pas oublier le module, sinon 0 se révélera en réalité égal à 1/3… En gros, j'ai obtenu une sorte de port de libffi, qui passe les tests les plus simples, et avec lequel glib se compile — j'ai décidé que je l'améliorerais plus tard si besoin. Pour anticiper, je dirai que, comme il s'avère, le compilateur n'a même pas inclus le code final de la fonction libffi.

Mais, comme je l'ai déjà dit, il y a certaines limitations, et parmi l'utilisation libre de divers comportements indéfinis, il y a une particularité plutôt désagréable — JavaScript ne supporte pas par conception le multithreading avec mémoire partagée. En principe, on peut même appeler cela une bonne idée, mais pas pour le portage de code dont l'architecture est basée sur des threads C. En fait, des expériences sont en cours dans Firefox pour supporter les workers partagés, et l'implémentation de pthread pour eux existe dans Emscripten, mais je n'ai pas voulu en dépendre. J'ai donc dû progressivement retirer le multithreading du code Qemu — c'est-à-dire localiser où les threads sont lancés, extraire le corps de la boucle qui s'exécute dans ce thread dans une fonction distincte, et appeler successivement ces fonctions depuis la boucle principale.

Deuxième tentative

À un certain moment, il est devenu évident que le problème était toujours présent, et que la répartition désordonnée de solutions de contournement dans le code n'allait pas mener à de bons résultats. Conclusion : il faut systématiser le processus d'ajout des solutions de contournement. Par conséquent, j'ai pris la version 2.4.1 qui était récente à l'époque (pas 2.5.0, parce qu'on ne sait jamais, il pourrait y avoir d'autres bugs non réglés dans la nouvelle version, et j'ai déjà assez de mes propres bugs), et en premier lieu, j'ai réécrit thread-posix.c. Donc, de manière sécurisée : si quelqu'un tentait d'exécuter une opération entraînant un blocage, la fonction abort() était immédiatement appelée — bien sûr, cela ne réglait pas tous les problèmes d'un coup, mais au moins, c'était plus agréable que de recevoir silencieusement des incohérences de données.

En fait, lors du portage de code vers JS, les options d'Emscripten aident beaucoup -s ASSERTIONS=1 -s SAFE_HEAP=1 — elles détectent certains types de comportements indéfinis comme des accès à des adresses non alignées (ce qui ne correspond pas du tout au code pour les typed arrays comme HEAP32[addr >> 2] = 1) ou l'appel d'une fonction avec un nombre incorrect d'arguments.

En fait, les erreurs d'alignement sont un sujet à part. Comme je l'ai déjà mentionné, Qemu dispose d'un backend d'interprétation codée appelé TCI (tiny code interpreter), et pour compiler et exécuter Qemu sur une nouvelle architecture, si on a de la chance, un compilateur C suffit. Mots-clés "si on a de la chance". Je n'ai pas eu de chance, et il s'avère que TCI utilise un accès non aligné lors de l'analyse de son bytecode. Cela signifie que sur des architectures comme ARM et d'autres nécessitant un accès aligné, Qemu se compile parce qu'il existe un backend TCG normal qui génère du code natif, mais savoir si TCI fonctionnera sur ces architectures est une autre question. Cependant, il s'avère que la documentation sur TCI mentionnait clairement quelque chose de similaire. En conséquence, des appels de fonctions pour la lecture non alignée ont été ajoutés dans le code, qui se sont révélés dans une autre partie de Qemu.

Destruction de tas

En fin de compte, l'accès non aligné dans TCI a été corrigé, et une boucle principale a été construite, appelant à tour de rôle le processeur, RCU et quelques autres petites choses. Et maintenant, je lance Qemu avec l'option -d exec,in_asm,out_asm, ce qui signifie qu'il faut indiquer quels blocs de code sont exécutés, tout en écrivant, au moment de la translation, quel était le code invité et quel est devenu le code hôte (dans ce cas, le bytecode). Cela démarre, exécute plusieurs blocs de traduction, écrit le message de débogage que j'ai laissé, que RCU va démarrer et... ça plante à abort() l'intérieur de la fonction free(). En fouillant dans la fonction free() , il a été possible de découvrir que dans l'en-tête du bloc de tas, qui se trouve dans les huit octets précédant la mémoire allouée, au lieu de la taille du bloc ou d'une autre information similaire, se trouvait des déchets.

La destruction de la pile — comme c'est mignon... Dans ce cas, il existe un moyen utile : assembler un binaire natif à partir des mêmes sources (si possible) et le faire passer sous Valgrind. Après un certain temps, le binaire était prêt. Je le lance avec les mêmes options — il plante encore à l'initialisation, sans atteindre l'exécution. Pas agréable, bien sûr — il semble que les sources n'étaient pas tout à fait les mêmes, ce qui n'est pas surprenant, car configure a détecté quelques options différentes, mais j'ai Valgrind — je vais d'abord corriger ce bogue, puis, si j'ai de la chance, l'original apparaîtra. Je relance tout cela sous Valgrind… Ouh-ouh, il a démarré, a bien passé l'initialisation et est passé à côté du bogue original sans un seul avertissement d'accès mémoire incorrect, sans parler des plantages. La vie ne m'a pas préparé à ça — un programme qui plantait cesse de planter lorsqu'il est exécuté sous Valgrind. Qu'est-ce que ça voulait dire — un mystère. Ma théorie est que puisque dans les environs de l'instruction actuelle, après le plantage à l'initialisation, gdb montrait une activité memset-a avec un pointeur valide en utilisant soit mmx, soit xmm registre, alors c'était peut-être une sorte d'erreur d'alignement, bien que cela reste peu crédible.

D'accord, Valgrind ne semble pas être d'une grande aide ici. Et c'est à ce moment-là que les choses se sont gâtées — tout semble démarrer, mais ça plante pour des raisons totalement inconnues à cause d'un événement qui aurait pu se produire des millions d'instructions auparavant. Pendant un long moment, c'était même flou sur la façon d'aborder le problème. Finalement, j'ai dû m'asseoir et déboguer. L'impression du contenu de l'en-tête a montré que ce n'était pas un nombre, mais plutôt des données binaires. Et, ô miracle, cette chaîne binaire a été trouvée dans le fichier du BIOS — donc, on pouvait dès lors affirmer avec une certaine confiance qu'il s'agissait d'un débordement de tampon, et même comprendre ce qui était écrit dans ce tampon. Eh bien, ensuite, comme cela, dans Emscripten, heureusement, il n'y a pas de randomisation de l'espace d'adresses, il n'y a pas de failles non plus, donc on peut écrire quelque part au milieu du code une sortie des données basées sur un pointeur de la dernière exécution, observer les données, examiner le pointeur, et si celui-ci n'a pas changé, obtenir des informations à méditer. Certes, il faut quelques minutes pour relier après chaque modification, mais que peut-on y faire. En fin de compte, une chaîne spécifique a été trouvée, copiant le BIOS du tampon temporaire vers la mémoire invitée — et, en effet, il n'y avait pas assez de place dans le tampon. La recherche de la source de cette adresse de tampon étrange a conduit à la fonction qemu_anon_ram_alloc dans le fichier oslib-posix.c — la logique était la suivante : il peut parfois être utile d'aligner l'adresse sur une énorme page de 2 Mo, donc nous demanderons d'abord un peu plus, et ensuite nous renverrons l'excédent grâce à mmap d'abord un peu plus, puis nous renverrons l'excédent grâce à munmap. Et si cet alignement n'est pas nécessaire, alors nous indiquerons au lieu de 2 Mo le résultat de getpagesize() — mmap qui retournera de toute façon une adresse alignée... Donc, dans Emscripten mmap il appelle simplement malloc, qui, bien sûr, n'aligne pas par page. En gros, le bug qui me dérangeait depuis quelques mois a été corrigé par un changement dans deux les lignes.

Caractéristiques de l'appel de fonctions

Et là, le processeur commence à calculer quelque chose, Qemu ne plante pas, mais l'écran ne s'allume pas, et le processeur se boucle rapidement, d'après la sortie. -d exec,in_asm,out_asm. Une hypothèse est apparue : les interruptions de minuterie (ou en fait toutes les interruptions) n'arrivent pas. Et en effet, si l'on déconnecte les interruptions de la build native, qui fonctionnait pour une raison quelconque, on obtient une image similaire. Mais le mystère ne résidait pas là : la comparaison des traces générées avec l'option mentionnée ci-dessus a montré que les trajectoires d'exécution divergent très tôt. Il faut dire que la comparaison de la sortie enregistrée avec celle générée par la build native n'est pas un processus entièrement mécanique. emrun La sortie de débogage avec la sortie de la build native — ce n'est pas tout à fait un processus mécanique. Je ne sais pas exactement comment un programme exécuté dans le navigateur se connecte à emrun, mais certaines lignes de la sortie se retrouvent échangées, donc la différence dans le diff n'est pas nécessairement une raison pour considérer que les trajectoires ont divergé. En général, il est devenu clair qu'en suivant les instructions ljmpl on change d'adresses différentes, et le bytecode est généré de manière fondamentalement différente : l'un contient une instruction d'appel d'une fonction helper C, tandis que l'autre n'en a pas. Après avoir googlé des instructions et étudié le code qui les traduit, il est devenu clair que, premièrement, directement avant celle-ci, un enregistrement dans le registre cr0 a été effectué — également à l'aide d'une fonction helper — pour faire passer le processeur en mode protégé, et deuxièmement, que la version js n'est jamais passée en mode protégé. En réalité, l'une des caractéristiques d'Emscripten est son incapacité à gérer un code similaire à celui de l'instruction call dans TCI, qui transforme tout pointeur vers une fonction en type long long f(int arg0, .. int arg9) — les fonctions doivent être appelées avec le bon nombre d'arguments. En cas de violation de cette règle, selon les paramètres de débogage, le programme peut soit planter (ce qui est bon), soit appeler une fonction complètement différente (ce qui sera triste à déboguer). Il y a aussi une troisième option — activer la génération de wrappers qui ajoutent / suppriment des arguments, mais en total, ces wrappers prennent beaucoup de place, alors que j'ai en fait juste besoin de légèrement plus d'une centaine de wrappers. Cela seul est déjà assez triste, mais il s'est avéré qu'il y avait un problème plus sérieux : dans le code généré des fonctions wrapper, les arguments étaient convertis, mais il se trouvait que la fonction avec les arguments générés était parfois non exécutée — comme dans ma mise en œuvre de libffi. Cela signifie que certains helpers ne s'exécutaient tout simplement pas.

Heureusement, dans Qemu, il existe des listes de helpers lisibles par machine sous forme de fichiers d'en-tête comme

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

Ils sont utilisés de manière assez amusante : d'abord, les macros sont redéfinies de la manière la plus bizarre DEF_HELPER_n, puis est inclus helper.h. Jusqu'à ce que la macro soit développée dans un initialiseur de structure et une virgule, et qu'un tableau soit ensuite défini, au lieu des éléments — #include <helper.h> En résultat, il y avait enfin une raison d'essayer la bibliothèque pyparsing, et un script a été écrit pour générer exactement les wrappers nécessaires et pour les fonctions requises.

Et voilà, après cela, le processeur semblait fonctionner. Semblait, parce que l'écran n'a pas été initialisé, bien que dans la compilation native, il ait été possible de lancer memtest86+. Il convient de préciser que le code des entrées/sorties bloquées de Qemu est écrit en coroutines. Emscripten a sa propre réalisation très complexe, mais il fallait aussi la supporter dans le code de Qemu, et le débogage du processeur peut être fait maintenant : Qemu supporte les options -kernel, -initrd, -append, grâce auxquelles il est possible de charger Linux ou, par exemple, memtest86+, sans utiliser du tout de périphériques de blocs. Mais voici le hic : dans la compilation native, on pouvait observer la sortie du noyau Linux sur la console avec l'option -nographic, mais depuis le navigateur, aucune sortie n'arrivait dans le terminal à partir duquel il a été lancé emrun, donc c'était incompréhensible : le processeur ne fonctionne pas ou la sortie graphique. Puis, il m'est venu à l'esprit d'attendre un peu. Il s'est avéré que "le processeur ne dort pas, mais clignote lentement", et après environ cinq minutes, le cœur a balancé une série de messages sur la console et a continué à se bloquer. Il est devenu clair que le processeur fonctionne, en général, et il fallait explorer le code de travail avec SDL2. Malheureusement, je ne sais pas comment utiliser cette bibliothèque, donc j'ai dû agir au hasard par endroits. À un moment donné, une ligne parallel0 a clignoté sur un fond bleu, ce qui m'a amené à quelques réflexions. Finalement, il s'est avéré que le problème était que Qemu ouvre plusieurs fenêtres virtuelles dans une même fenêtre physique, entre lesquelles on peut basculer avec Ctrl-Alt-n : dans la compilation native, cela fonctionne, dans Emscripten — non. Après avoir éliminé les fenêtres superflues avec les options -monitor none -parallel none -serial none et en forçant le rafraîchissement de tout l'écran à chaque frame, tout a soudainement bien fonctionné.

Coroutines

Ainsi, l'émulation dans le navigateur fonctionne, mais il n'y a rien d'intéressant de type disquette que l'on puisse lancer, car il n'y a pas d'entrée-sortie par blocs — il est nécessaire de mettre en œuvre un support pour les coroutines. Qemu possède déjà plusieurs backends de coroutine, mais en raison des particularités de JavaScript et du générateur de code Emscripten, il n'est pas possible de jongler simplement avec les piles. On pourrait penser que "tout est perdu, le plâtre est retiré", mais les développeurs d'Emscripten ont déjà pris tout en charge. C'est réalisé de manière assez amusante : pourquoi ne pas appeler des fonctions suspectes comme emscripten_sleep et quelques autres utilisant le mécanisme Asyncify, ainsi que les appels par pointeur et les appels de n'importe quelle fonction, où l'un des deux cas précédents peut se produire plus bas dans la pile. Et maintenant, avant chaque appel suspect, nous allons allouer un contexte asynchrone, et juste après l'appel — vérifier s'il y a eu un appel asynchrone, et si c'est le cas, nous sauvegarderons toutes les variables locales dans ce contexte asynchrone, indiquerons quelle fonction doit reprendre le contrôle lorsque nous devrons continuer l'exécution, et sortirons de la fonction actuelle. Voilà où il y a un champ d'étude pour l'effet de dépeçage — pour les besoins de la continuation de l'exécution du code après le retour d'un appel asynchrone, le compilateur génère des "morceaux" de fonction, commençant après l'appel suspect — ainsi, s'il y a n appels suspects, la fonction sera dépeçée environ n/2 fois — cela sans compter qu'il faut également ajouter des sauvegardes de certaines variables locales après chaque appel potentiellement asynchrone. Par la suite, j'ai même dû écrire un script simple en Python qui, pour un ensemble donné de fonctions particulièrement dépeçées, qui, selon les suppositions, "ne laissent pas passer l'asynchronicité à travers elles" (c'est-à-dire qu'elles ne déclenchent pas le déroulement de la pile et tout ce que je viens de décrire), indique quelles fonctions doivent être ignorées par le compilateur concernant les appels par pointeur, afin que ces fonctions ne soient pas considérées comme asynchrones. Car des fichiers JS de près de 60 Mo, c'est clairement trop — au moins 30. Pourtant, une fois, j'ai configuré un script de construction et j'ai accidentellement supprimé les options de l'éditeur de liens, parmi lesquelles se trouvait -O3J'exécute le code généré, et Chromium consomme toute la mémoire et plante. Par la suite, j'ai regardé par accident ce qu'il essayait de charger... Eh bien, que puis-je dire, je serais également bloqué si on me demandait d'analyser et d'optimiser du JavaScript de plus de 500 Mo.

Malheureusement, les vérifications dans le code de la bibliothèque de support Asyncify n'étaient pas tout à fait compatibles avec longjmp- qui sont utilisés dans le code du processeur virtuel, mais après un petit patch désactivant ces vérifications et restaurant de force les contextes comme si tout allait bien, le code a fonctionné. Et là, les choses sont devenues étranges : parfois, des vérifications dans le code de synchronisation se déclenchaient — celles qui arrêtent brutalement le code si, selon la logique d'exécution, il doit se bloquer — quelqu'un essayait de capturer un mutex déjà acquis. Heureusement, ce n'était pas un problème logique dans le code sérialisé — j'avais simplement utilisé la fonctionnalité standard de la boucle principale fournie par Emscripten, mais parfois un appel asynchrone déroulait complètement la pile, et à ce moment-là, setTimeout de la boucle principale se déclenchait — ainsi, le code entrait dans une itération de la boucle principale sans sortir de l'itération précédente. J'ai réécrit avec une boucle infinie et emscripten_sleep, et les problèmes avec les mutex ont cessé. Le code est même devenu plus logique — après tout, je n'ai pas de code qui prépare une nouvelle image d'animation — le processeur fait simplement des calculs et l'écran se met à jour périodiquement. Cependant, les problèmes ne se sont pas arrêtés là : parfois, l'exécution de Qemu se terminait tout simplement sans aucune exception ni erreur. À ce moment-là, j'ai laissé tomber, mais pour aller de l'avant, je dirai que le problème était le suivant : le code des coroutines, en réalité, n'utilise pas vraiment setTimeout (ou, du moins, pas aussi souvent qu'on pourrait le penser) : la fonction emscripten_yield se contente de définir un drapeau d'appel asynchrone. En fait, ce qui est important, c'est que emscripten_coroutine_next n'est pas une fonction asynchrone : elle vérifie le drapeau, le réinitialise et transmet le contrôle là où il faut. Cela signifie que c'est là que le déroulement de la pile s'arrête. Le problème était qu'à cause d'un use-after-free, qui se manifestait lorsque le pool de coroutines était désactivé, parce que je n'avais pas copié la ligne de code importante à partir du backend de coroutine existant, la fonction qemu_in_coroutine retournait true alors qu'elle aurait dû retourner false. Cela entraînait un appel emscripten_yield, au-dessus duquel la pile ne montait pas emscripten_coroutine_next, la pile s'étendait jusqu'au sommet, mais aucune setTimeout, comme je l'ai déjà dit, n'était affiché.

Génération de code JavaScript

Et voici, en fait, le "revers de la viande hachée" promis. En réalité, non. Bien sûr, si vous lancez Qemu dans le navigateur, et en lui — Node.js, alors, après la génération de code dans Qemu, nous obtiendrons un JavaScript complètement différent. Mais tout de même, quel que soit le cas, il y a une certaine rétro-conversion.

Pour commencer, un peu sur le fonctionnement de Qemu. Je vous demande immédiatement de me pardonner : je ne suis pas un développeur professionnel de Qemu et mes conclusions peuvent être parfois erronées. Comme on dit, "l'avis d'un étudiant ne doit pas nécessairement coïncider avec celui de l'enseignant, l'axiomatique de Peano et le bon sens". Qemu a un certain nombre d'architectures invitées prises en charge, et pour chacune, il existe un répertoire comme target-i386. Lors de la compilation, il est possible d'indiquer le support de plusieurs architectures invitées, mais le résultat sera simplement plusieurs binaires. Le code pour le support de l'architecture invitée, à son tour, génère certaines opérations internes de Qemu, que TCG (Tiny Code Generator) transforme ensuite en code machine de l'architecture hôte. Comme indiqué dans le fichier readme se trouvant dans le répertoire tcg, à l'origine, cela faisait partie d'un compilateur C normal, qui a ensuite été adapté au JIT. Par conséquent, par exemple, l'architecture cible dans les termes de ce document — ce n'est plus l'architecture invitée, mais celle de l'hôte. À un moment donné, un autre composant est apparu — l'Interprète de Petite Code (TCI), qui est censé exécuter le code (pratiquement les mêmes opérations internes) en l'absence de générateur de code pour une architecture hôte spécifique. En fait, comme indiqué dans sa documentation, cet interprète peut ne pas toujours fonctionner aussi bien que le générateur de code JIT, non seulement quantitativement en termes de vitesse, mais aussi qualitativement. Bien que je ne sois pas sûr que sa description soit entièrement actuelle.

Au départ, j'ai essayé de créer un backend TCG complet, mais je me suis rapidement perdu dans le code source et la documentation des instructions de bytecode pas toujours compréhensible, donc j'ai décidé d'envelopper l'interprète TCI. Cela a immédiatement apporté plusieurs avantages :

• lors de la mise en œuvre du générateur de code, on pouvait se référer non pas à la description des instructions, mais au code de l'interprète
• Il est possible de générer des fonctions non pas pour chaque bloc de traduction rencontré, mais seulement après la centième exécution, par exemple.
• En cas de modification du code généré (ce qui semble possible, à en juger par les fonctions dont les noms contiennent le mot patch), je devrai invalider le code JavaScript généré, mais au moins j'aurai de quoi le régénérer.

Quant au troisième point, je ne suis pas sûr que le patching soit possible après la première exécution du code, mais les deux premiers points suffisent.

À l'origine, le code était généré sous forme d'un gros switch basé sur l'adresse de l'instruction bytecode source, mais après avoir rappelé un article sur Emscripten, l'optimisation du JS généré et la relooping, j'ai décidé de générer un code plus humain, d'autant plus qu'expérimentalement, il s'est avéré que le seul point d'entrée dans le bloc de traduction est son début. Cela a été fait, et après un certain temps, un générateur de code a été créé, générant du code avec des if (bien que sans boucles). Mais voilà le problème, il échouait en donnant un message indiquant que l'instruction avait une longueur incorrecte. Par ailleurs, la dernière instruction à ce niveau de récursion était brcond. Bien, j'ajouterai une vérification identique lors de la génération de cette instruction avant l'appel récursif et après, et... aucune d'entre elles ne s'est exécutée, mais après le switch sur l'assert, tout de même, cela a échoué. Finalement, après avoir étudié le code généré, j'ai compris qu'après le switch, le pointeur sur l'instruction actuelle se rechargeait à partir de la pile et était probablement écrasé par le code JavaScript généré. Et c'était le cas. L'augmentation du tampon d'un mégaoctet à dix n'a rien résolu, et il est devenu évident que le générateur de code tournait en rond. J'ai dû vérifier que nous ne dépassions pas les limites du TB actuel, et si nous le dépassions, alors donner l'adresse du prochain TB avec un signe moins, afin que nous puissions continuer l'exécution. D'ailleurs, cela résout le problème de "quelles fonctions générées invalider si ce morceau de bytecode a changé ?" - il faut invalider uniquement la fonction qui correspond à ce bloc de traduction. Au fait, bien que j'ai tout débogué dans Chromium (puisque j'utilise Firefox et qu'il est plus facile pour moi d'utiliser un autre navigateur pour les expériences), Firefox m'a aidé à résoudre des incompatibilités avec la norme asm.js, après quoi le code a commencé à fonctionner plus rapidement dans Chromium.

Exemple de code généré

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"]

Conclusion

Donc, le travail n'est toujours pas terminé, mais j'en ai assez de perfectionner ce long projet en secret. J'ai donc décidé de publier pour l'instant ce qui existe. Le code est parfois un peu brut, car c'est une expérience, et il n'est pas clair à l'avance ce qu'il faut faire. Il est probablement judicieux de préparer des commits atomiques normaux au-dessus d'une version plus moderne de Qemu. Pour l'instant, il y a une branche dans Git au format blog : à chaque "niveau" un peu franchi, un commentaire détaillé en russe a été ajouté. En fait, cet article est en grande partie un résumé des résultats. git log.

Vous pouvez essayer tout ça ici (attention, trafic).

Ce qui fonctionne déjà :

• Un processeur virtuel x86 fonctionne
• Il y a un prototype fonctionnel de générateur de code JIT qui convertit le code machine en JavaScript
• Il y a une préparation pour la compilation d'autres architectures invitées 32 bits : vous pouvez actuellement admirer un Linux qui se fige dans le navigateur au stade de chargement pour l'architecture MIPS.

Que peut-on encore faire

• Accélérer l'émulation. Même en mode JIT, cela semble fonctionner plus lentement que Virtual x86 (mais potentiellement, il existe tout un Qemu avec beaucoup de matériel et d'architectures émulés)
• Créer une interface correcte — je ne suis pas vraiment un développeur web, donc pour l'instant j'ai refait le shell standard d'Emscripten, comme j'ai pu.
• Essayer d'exécuter des fonctions plus complexes de Qemu — réseau, migration de VM, etc.
• Mise à jour : Il faudra soumettre dans l'upstream d'Emscripten mes quelques contributions et rapports de bugs, comme l'ont fait les porteurs précédents de Qemu et d'autres projets. Merci à eux pour la possibilité d'utiliser implicitement leur contribution à Emscripten dans le cadre de ma tâche.

Source : habr.com