cli-anything-lldb

LLDB-CLI-Fähigkeit

Nutzen Sie diese CLI, um strukturierte LLDB-Debugging-Workflows mit JSON-Ausgabe durchzuführen.

Fähigkeiten

• Debug-Ziel aus ausführbarem Pfad erstellen
• Prozess starten oder an PID/Name anhängen
• Breakpoints verwalten (setzen/auflisten/löschen/aktivieren/deaktivieren)
• Threads, Frames, lokale Variablen und Backtrace inspizieren
• Ausdrücke im aktuellen Frame auswerten
• Prozessspeicher lesen/suchen
• Core-Dumps laden
• Interaktives REPL mit persistentem Sitzungszustand
• Formaler stdio-Debug-Adapter-Protokoll-Server für KI-/Editor-Clients

Schnellbefehle

cli-anything-lldb --json target create --exe /pfad/zu/ausfuehrbar
cli-anything-lldb --json process launch --arg foo --arg bar
cli-anything-lldb --json breakpoint set --function main
cli-anything-lldb --json breakpoint set --function PluginEntry --allow-pending
cli-anything-lldb --json process continue
cli-anything-lldb --json process interrupt
cli-anything-lldb --json thread backtrace --limit 20
cli-anything-lldb --json frame locals
cli-anything-lldb --json expr "myVar"
cli-anything-lldb --json memory read --address 0x1000 --size 64
cli-anything-lldb --json session close

Debug-Adapter-Protokoll

Verwenden Sie den DAP-Einstiegspunkt, wenn ein KI-Client einen echten Debug-Adapter-Lebenszyklus benötigt, anstatt separate CLI-Befehle aufzurufen:

cli-anything-lldb-dap
cli-anything-lldb-dap --profile /pfad/zu/stop-regeln.json

oder:

cli-anything-lldb dap
cli-anything-lldb dap --profile /pfad/zu/stop-regeln.json

Der DAP-Server kommuniziert über stdio-Content-Length-Frames und benötigt exklusive stdout. Geben Sie keine Logs über stdout aus, während er läuft. Unterstützte Anfragen umfassen initialize, launch, attach, configurationDone, setBreakpoints, setFunctionBreakpoints, threads, stackTrace, scopes, variables, setVariable, evaluate, continue, pause, next, stepIn, stepOut, source, loadedSources, readMemory, modules, exceptionInfo, disassemble und disconnect.

DAP-Variablen können Kind-Referenzen für Strukturen/Klassen/Arrays verfügbar machen. Verwenden Sie setVariable nur im gestoppten Zustand; LLDB kann Schreibvorgänge auf optimierte oder schreibgeschützte Werte ablehnen.

Für langlebige GUI-Debuggee-Programme ist continue im DAP aus Clientsicht nicht blockierend: Der Adapter sendet zuerst die Antwort und das continued-Ereignis, dann wartet er im Hintergrundthread auf LLDB. pause im DAP verwendet LLDB-Async-Interrupt. Wenn ein Agent Breakpoints ändern muss, während das Debuggee läuft, unterbricht der Adapter zuerst und wartet auf einen gestoppten Zustand, bevor er LLDB-Breakpoints mutiert; falls das Ziel nicht rechtzeitig stoppt, wiederholen Sie den Vorgang nach einem expliziten pause/stopped-Zyklus.

Für GUI-Apps, die beim debugger-internen Start oder bei Shader-JIT-Breakpoints stoppen, akzeptieren launch und attach das nicht-standardmäßige boolesche Argument autoContinueInternalBreakpoints. Aktivieren Sie es nur, wenn diese internen Stopps für die Aufgabe Rauschen sind; der Adapter sendet ein output-Ereignis vor dem automatischen Fortsetzen. Für zielspezifisches Rauschen bevorzugen Sie strukturierte Stoppregeln über inline stopRules oder eine externe stopRuleProfile/--profile JSON-Datei. Regeln können nach reason, module, function und/oder regex übereinstimmen und dann entweder stop mit klaren cliAnythingStop.origin-Metadaten durchführen oder automatisch continue ausführen. Verwenden Sie Profile für Apps wie C4D, damit deren NVIDIA-Shader-JIT-/Start-Traps außerhalb des generischen Adapters bleiben.

DAP-stopped-Ereignisse enthalten body.cliAnythingStop.origin: manualPause für eine Client-Pause-Anfrage, internalTrap für eine passende interne Regel und debuggee für normale Programmstopps. Vorhandene cli-anything-lldb-dap-Prozesse laden keine neuen Code- oder Profilinhalte heiß; starten Sie den Adapter neu und hängen Sie erneut an oder starten Sie erneut, bevor neue Regeln angewendet werden.

Befehlsgruppen

target

cli-anything-lldb --json target create --exe /pfad/zu/ausfuehrbar [--arch x86_64]
cli-anything-lldb --json target info

process

cli-anything-lldb --json process launch [--arg ARG ...] [--env KEY=VALUE ...] [--cwd DIR] [--stop-at-entry]
cli-anything-lldb --json process attach --pid 1234
cli-anything-lldb --json process attach --name myapp --wait-for
cli-anything-lldb --json process continue
cli-anything-lldb --json process interrupt
cli-anything-lldb --json process detach
cli-anything-lldb --json process info

breakpoint

cli-anything-lldb --json breakpoint set --function main
cli-anything-lldb --json breakpoint set --file main.c --line 42 --condition "i > 10"
cli-anything-lldb --json breakpoint set --function LateLoadedSymbol --allow-pending
cli-anything-lldb --json breakpoint list
cli-anything-lldb --json breakpoint delete --id 1
cli-anything-lldb --json breakpoint enable --id 1
cli-anything-lldb --json breakpoint disable --id 1

thread / frame / step

cli-anything-lldb --json thread list
cli-anything-lldb --json thread select --id 11111
cli-anything-lldb --json thread backtrace --limit 50
cli-anything-lldb --json frame select --index 0
cli-anything-lldb --json frame info
cli-anything-lldb --json frame locals
cli-anything-lldb --json step over
cli-anything-lldb --json step into
cli-anything-lldb --json step out

expr / memory / core

cli-anything-lldb --json expr "argc"
cli-anything-lldb --json memory read --address 0x1000 --size 128
cli-anything-lldb --json memory find "needle" --start 0x1000 --size 4096
cli-anything-lldb --json core load --path /pfad/zu/core

Hinweise zur Nutzung durch Agenten

• Bevorzugen Sie --json für alle automatisierten Abläufe.
• Separate Nicht-REPL-Aufrufe teilen sich standardmäßig einen persistenten Sitzungsdienst.
• Verwenden Sie --session-file PFAD oder CLI_ANYTHING_LLDB_SESSION_FILE, um eine explizite Sitzung für eine Aufgabe festzulegen.
• Führen Sie cli-anything-lldb --json session close aus, wenn Sie fertig sind, damit angehängte Prozesse getrennt und gestartete Debuggees bereinigt werden.
• Verwenden Sie REPL, wenn eine menschenähnliche interaktive Shell bequemer ist, nicht weil Persistenz erforderlich ist.
• Nicht aufgelöste CLI-Breakpoints schlagen standardmäßig fehl; übergeben Sie --allow-pending nur, wenn ein zukünftiges Modul-/Symbol-Laden erwartet wird.
• Nicht aufgelöste DAP-Breakpoints verwenden Protokoll-Semantik: verified: false bis aufgelöst.
• DAP continue ist für langlebige GUI-Prozesse nicht blockierend, und DAP pause verwendet asynchronen Interrupt.
• DAP-Breakpoint-Änderungen während eines aktiven Continue unterbrechen zuerst und warten auf einen gestoppten Zustand, bevor LLDB mutiert wird.
• Verwenden Sie DAP-Stoppregel-Profile für app-spezifische interne Traps; starten Sie nach Profiländerungen neu und hängen Sie erneut an/starten Sie erneut.
• memory find verwendet eine chunked scan, die auf 1 MiB pro Aufruf begrenzt ist.
• Rufen Sie target create vor Prozess- oder Core-Befehlen auf.
• Erwarten Sie strukturierte Fehler: {"error": "...", "type": "..."}