lbfdump ist das, was objdump für ELF ist: ein Inspektor für LBF-Dateien. Es erkennt das Format am Magic und liest beide Ausprägungen, die der Compiler erzeugt:
| Magic | Format | Erzeugt mit | Inhalt |
|---|---|---|---|
LYX! (4C 59 58 21) | Native Genesis | lyxc –target=lyxos | Blockbasiertes Maschinencode-Programm |
LBF\0 (4C 42 46 00) | IR-Bytecode | lyxc –target=lyxos –emit=lbf | Kompakter IR: Header, String-Pool, Funktionen, 20-Byte-Instruktionen |
Das Werkzeug ist selbst in Lyx geschrieben und übersetzt zu einem nativen Linux-ELF — es läuft also auf dem Entwicklungsrechner, ohne LyxOS. Seine Layout-Konstanten importiert es aus dem Compiler (src/std/lyxos/lbf_layout.lyx), kann also nicht vom tatsächlichen Dateiformat abdriften.
→ Tools & Compiler · Compiler-Parameter · LBF-Format · LyxOS
lbfdump [Optionen] <datei.lbf>
| Kurz | Lang | Wirkung |
|---|---|---|
-f | --file-headers | Header bzw. Genesis-Block ausgeben |
-h | --section-headers | Sektionen ausgeben |
-p | --private | TLV-Pool — nur LYX!: Capabilities, Intent, Section-Map |
-t | --syms | Symbol-/Funktionstabelle — nur LBF\0 |
-s | --full-contents | Hex-Dump von Code bzw. Block-Nutzlast |
-d | --disassemble | Disassembly (LBF\0; siehe Kasten) |
-x | --all-headers | LYX!: -f -p -h · LBF\0: -f -h -t |
-H | --help | Hilfe |
$ lyxc add.lyx --target=lyxos -o add.lbf
$ lbfdump -x add.lbf
=== LBF Genesis (LYX! native) ===
Magic: LYX! (4C 59 58 21)
Target arch: x86-64
Entry point: 0x0000000000400000
File size: 8192 bytes (2 blocks)
File CRC32C: 0xb3318131 (stored)
Stack size: 131072 bytes
Compiler: lyxc
=== TLV Pool ===
[0x05] Capabilities: 0x0000000000000000 (none)
[0x08] Lifecycle: kind=0x00
[0x09] Section Map: .text start=1 count=1 (R/X)
[0x09] Section Map: .rodata start=1 count=1 (R)
=== Sections (block inventory) ===
.text 1 block(s) R/X
.rodata 1 block(s) R
.data 0 block(s) R/W
.bss 0 block(s) R/W
Blocks: 2 total (incl. Genesis)
Der TLV-Pool ist der interessante Teil: Dort steht, was das Programm über sich selbst mitteilt. Die Einträge sind tag u8 + len u16 + value; bekannt sind 1 Human-Intent, 2 Dep-Hash-Graph, 3 Symbol-Interface, 4 ISA-Extensions, 5 Capabilities, 6 Source-Map, 7 Build-Manifest, 8 Lifecycle, 9 Section-Map.
Die Zeile Capabilities ist der schnellste Weg zu prüfen, welche Rechte ein fertiges Binary tatsächlich verlangt — unabhängig davon, was im Quelltext steht (→ Capabilities).
Jeder Block ist 4096 Byte groß: 64 Byte Kopf, 4032 Byte Nutzlast. Block 0 trägt die Genesis-Nutzlast ab Dateioffset 64.
$ lyxc add.lyx --target=lyxos --emit=lbf -o add_ir.lbf
$ lbfdump -f -t add_ir.lbf
=== LBF File Header (LBF\0 IR) ===
Magic: LBF\0 (4C 42 46 00)
Version: 1
Entry index: 1
Functions: 2
Code offset: 0x00000079
Instructions: 16
File size: 441 bytes
=== Symbols (functions) ===
Idx Name
0 Add
1 main <entry>
Aufbau: Header (64 B) + String-Pool + Funktionstabelle (24 B je Eintrag) + Instruktionen (20 B je Stück). Eine Instruktion ist opcode u16 · dest u16 · a u32 · b u32 · imm i64, wobei dest = 0xFFFF „kein Ziel„ und a/b = 0xFFFFFFFF „unbenutzt“ heißt.
$ lbfdump -d add_ir.lbf
=== Disassembly: Add ===
0: LOAD_LOCAL r3 a=0 imm=0
1: LOAD_LOCAL r4 a=1 imm=0
2: ADD r5 a=3 b=4 imm=0
3: STORE_LOCAL r2 a=5 imm=0
4: JMP imm=0
Zwei Voraussetzungen für-d:
* Die Tabellenlbf_opcodes.tsvundlbf_builtins.tsvwerden im aktuellen Verzeichnis gesucht, nicht neben dem Programm. Ohne sie erscheinen statt der Namen nur Zahlen — die beiden Dateien liegen imlbfdump-Quellverzeichnis und gehören ins Arbeitsverzeichnis kopiert.
* Für einLYX!-Binary geht-dnicht: Dort steht Maschinencode, dessen Disassembly Capstone braucht.lbfdumpmeldet das und verweist auf-sfür den Hex-Dump.
lyxc lbfdump.lyx -I /home/andreas/PhpstormProjects/aurum --target=linux -o lbfdump
Die Ausgabe wird gegen den kanonischen Referenz-Dumper src/tools/lbf/dumper.lyx des Compilers gegengeprüft.
Geprüft mit lbfdump 1.1 und lyxc 1.0.15G.
Letzte Aktualisierung: 2026-08-11