Zielsysteme

Alle Ziele auf einen Blick

Windows: PE-Dateien für Intel und ARM, 32 und 64 Bit

Mit .format pe schreibt der Assembler eine fertige Windows-Datei: DOS-Stub, PE-Kopf, Abschnitte und Import-Tabelle. Der Quelltext enthält nur Code (.code), Daten (.data) und die Funktionen, die er aus DLLs braucht (.import). Ein Linker ist nicht nötig.

.format pe console
.arch i386
.import msvcrt.dll printf, exit

.code
start:
    push dword msg      ; the argument on the stack
    call [printf]       ; through the import table
    add esp, 4          ; printf does not clean up
    push 0
    call [exit]

.data
msg db 'Hello, World!', 10, 0

.format pe console
.arch x64
.import msvcrt.dll printf, exit

.code
start:
    sub rsp, 40         ; shadow space, stack aligned
    lea rcx, [msg]      ; first argument in rcx
    call [printf]
    xor ecx, ecx
    call [exit]

.data
msg db 'Hello, World!', 10, 0

Dasselbe für ARM steht mit Erklärung auf der Seite Windows on ARM. .format pe gui macht ein Fensterprogramm statt eines Konsolenprogramms (messagebox_*.asm, window_*.asm).

Debuggen. Ein 32-Bit-Programm für Intel debuggt Asmonite selbst, auf diesem Rechner. Ein x64-Programm läuft unter dem Hilfsprozess asmodbgx64, weil Asmonite selbst ein 32-Bit-Programm ist; auch das geschieht auf diesem Rechner (oder auf einem anderen mit demselben Debug-Server). ARM-Programme laufen auf einem Windows-on-ARM-Rechner mit dem Debug-Server asmodbg oder asmodbg64, verbunden über ssh oder direkt im Netz; auf dem ARM-Rechner selbst auch lokal. Vor jedem Start prüft Asmonite die erzeugte Datei: Kopf, Abschnitte, Einsprung und ob es die importierten DLLs und Funktionen wirklich gibt.

DOS: .COM und .EXE in QEMU

Mit .format binary und .arch x86_real schreibt Asmonite 16-Bit-Code für den Real Mode, Byte für Byte so, wie er im Quelltext steht.

Debuggen. F9 legt das Programm auf ein Festplatten-Abbild und startet QEMU mit FreeDOS; das Hilfsprogramm dbgload.com lädt es dort, und der Debugger hält an der ersten Zeile. Breakpoints, Schritte, Register und Speicher funktionieren wie bei Windows-Programmen; ein zweiter Lauf braucht kein neues Booten. qemu\run_freedos.bat holt einmal die FreeDOS-Diskette, QEMU selbst wird mit qemu\install_qemu.bat eingerichtet. Dismonite öffnet fertige DOS-Programme (MZ), findet Code, Daten, Sprungtabellen und das Programmende und lässt dich Bereiche von Hand markieren.

ARM-Linux: ELF-Programme in QEMU

Dieses Ziel ist eines von Dismonite: Es liest ELF-Dateien für 32-Bit-ARM, wie sie GCC oder ein anderer Compiler unter Linux erzeugt, und debuggt sie in einem Raspberry Pi OS, das in QEMU läuft.

• Ansehen: Dismonite zerlegt den Code ab dem Einsprung, mit den Namen aus der Symboltabelle, und zeigt ARM- und Thumb-Befehle.
• Ausführen und debuggen: qemu\run_buster.bat startet das Gastsystem; der Debugger erreicht es über ssh und gdbserver, kopiert das Programm hinein und hält am Einsprung. Läuft der Gast nicht, fragt Dismonite, ob es ihn starten soll.
• Grenze: Asmonite schreibt (noch) keine ELF-Dateien. Ein eigenes Linux-Programm entsteht mit den Werkzeugen von Linux; Asmonite und Dismonite helfen beim Lesen und Debuggen.

Raspberry Pi Pico und Pico 2

Mit .target pico (RP2040, Cortex-M0+) oder .target pico2 (RP2350, Cortex-M33 oder RISC-V Hazard3) schreibt Asmonite die Bytes für das Board und prüft sie: die erlaubten Befehle, RAM und Flash, beim Pico den boot2-Block, beim Pico 2 den IMAGE_DEF-Block. F7 bringt das Programm über eine CMSIS-DAP-Debug-Probe ins RAM oder in den Flash und hält bei _start, ohne OpenOCD und ohne SDK. Ohne Probe geht es als UF2-Datei auf das BOOTSEL-Laufwerk.

Die Seite zum Raspberry Pi Pico →

Weiter