ish-app/ishLinux-Shell für iOS
Ein Projekt, um eine Linux-Shell auf iOS zum Laufen zu bringen, mittels usermode x86-Emulation und Syscall-Übersetzung.
Den aktuellen Stand des Projekts finden Sie im Reiter „Issues“ und in den Commit-Logs.
Dieses Projekt enthält ein Git-Submodul. Stellen Sie sicher, dass Sie es mit --recurse-submodules klonen oder nach dem Klonen git submodule update --init ausführen.
Sie benötigen diese Dinge, um das Projekt zu bauen:
pip3 install meson)brew install llvm, auf Linux: sudo apt install clang lld oder sudo pacman -S clang lld oder ähnliches)sudo apt install libsqlite3-dev aus)brew install libarchive, sudo port install libarchive, sudo apt install libarchive-dev) TODO: Diese Abhängigkeit bündelnÖffnen Sie das Projekt in Xcode, öffnen Sie iSH.xcconfig und ändern Sie ROOT_BUNDLE_IDENTIFIER in etwas Einzigartiges. Sie müssen auch die Entwicklerteam-ID in den Build-Einstellungen des Projekts (nicht des Targets!) aktualisieren. Klicken Sie dann auf „Run“. Es gibt Skripte, die alles Weitere automatisch erledigen sollten. Wenn Sie auf Probleme stoßen, öffnen Sie ein Issue und ich werde versuchen zu helfen.
Um Ihre Umgebung einzurichten, wechseln Sie in das Projektverzeichnis und führen Sie meson build aus, um ein Build-Verzeichnis in build zu erstellen. Wechseln Sie dann in das Build-Verzeichnis und führen Sie ninja aus.
Um ein eigenständiges Alpine-Linux-Dateisystem einzurichten, laden Sie das Alpine-minirootfs-tarball für i386 von der Alpine-Website herunter und führen Sie ./tools/fakefsify aus, wobei das minirootfs-tarball das erste Argument und der Name des Ausgabeverzeichnisses das zweite Argument ist. Dann können Sie Dinge innerhalb des Alpine-Dateisystems mit ./ish -f alpine /bin/sh ausführen, vorausgesetzt das Ausgabeverzeichnis heißt alpine. Falls tools/fakefsify in Ihrem Build-Verzeichnis nicht existiert, liegt das möglicherweise daran, dass libarchive auf Ihrem System nicht gefunden wurde (siehe oben für Installationsmöglichkeiten).
Sie können ish durch tools/ptraceomatic ersetzen, um das Programm in einem echten Prozess auszuführen und Schritt für Schritt zu verfolgen und die Register bei jedem Schritt zu vergleichen. Ich verwende es zum Debuggen. Erfordert 64-Bit-Linux 4.11 oder neuer.
iSH verfügt über mehrere Logging-Kanäle, die zur Build-Zeit aktiviert werden können. Standardmäßig sind alle deaktiviert. So aktivieren Sie sie:
ISH_LOG in iSH.xcconfig auf eine durch Leerzeichen getrennte Liste von Log-Kanälen.meson configure -Dlog="<durch Leerzeichen getrennte Liste von Log-Kanälen>" aus.Verfügbare Kanäle:
strace: Der nützlichste Kanal, protokolliert die Parameter und Rückgabewerte fast jedes Systemaufrufs.instr: Protokolliert jede Anweisung, die vom Emulator ausgeführt wird. Dies verlangsamt die Dinge erheblich.verbose: Debug-Logs, die in keine andere Kategorie passen.DEFAULT_CHANNEL, um zu sehen, ob seit der Aktualisierung dieser Liste weitere Log-Kanäle hinzugefügt wurden.Vielleicht das Interessanteste, was ich als Teil von iSH geschrieben habe, ist der Interpreter. Es ist nicht wirklich ein JIT, da er keinen Maschinencode anvisiert. Stattdessen erzeugt er ein Array von Zeigern auf Funktionen, die als „Gadgets“ bezeichnet werden, und jedes Gadget endet mit einem Tail-Call zur nächsten Funktion – ähnlich der Threaded-Code-Technik, die von einigen Forth-Interpretern verwendet wird. Das Ergebnis ist eine Geschwindigkeitssteigerung von etwa 3-5x im Vergleich zur Emulation mit einer einfachen Switch-Dispatch.
Leider habe ich die Entscheidung getroffen, fast alle Gadgets in Assemblersprache zu schreiben. Das war wahrscheinlich eine gute Entscheidung in Bezug auf die Leistung (auch wenn ich es nie genau wissen werde), aber eine schreckliche Entscheidung in Bezug auf Lesbarkeit, Wartbarkeit und meinen Verstand. Die Menge an Unsinn, den ich vom Compiler/Assembler/Linker ertragen musste, ist irre. Es ist, als ob ein Dämon darin steckt, der dafür sorgt, dass mein Code ausreichend deformiert ist, und falls nicht, erfundene dumme Gründe findet, warum er nicht kompilieren sollte. Um bei diesem Code einigermaßen bei Verstand zu bleiben, musste ich Best Practices bei der Code-Struktur und Benennung ignorieren. Sie werden Makros und Variablen mit so aussagekräftigen Namen wie ss und s und a finden. Assembler-Makros, die über jedes Maß verschachtelt sind. Und um dem Ganzen die Krone aufzusetzen, gibt es fast keine Kommentare.
Also eine Warnung: Längere Exposition gegenüber diesem Code kann zu Verlust des Verstandes, Alpträumen über GAS-Makros und Linker-Fehlern oder einer beliebigen Anzahl anderer lähmender Nebenwirkungen führen. Dieser Code ist dem Bundesstaat Kalifornien als krebserregend, erbgutschädigend und fortpflanzungsschädigend bekannt.