[GH-ISSUE #1267] [Feature] Live native debugging through x64dbg, GDB and LLDB adapters #456

New issue

Open

opened 2026-10-15 18:25:12 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:25:12 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1267

Before submitting

I searched open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Process capture or runtime observation

Current limitation

REA needs a reusable live native debugging workflow: select an executable or an existing process, stop at an analyst-selected location, inspect its actual state, step/resume, and use the observations to test a reverse-engineering hypothesis. Windows x64dbg and Linux GDB are the first intended providers; LLDB is another candidate for Linux/macOS.

This is a deferred roadmap, opened at the owner's request so the work is not forgotten. Current work remains bug fixes, stability and usability; this issue does not start implementation or a release.

Research baseline: REA main 552634d634655a722b2204cfbc4b29f6d442c294, 2026-10-09. Parent: #32. Continue the live-debugger increment described in closed #969; its shipped offline ELF and recorded-core work remains complete. Coordinate native instrumentation with #968 and firmware/Android use cases with #718 / #717.

Existing capabilities do not establish general live debugger control:

Ghidra/Hopper/IDA provide their own static/database analysis boundaries.
inspect_recorded_crash inspects historical crash evidence, with optional core-only GDB/pwndbg mapping context.
observe_native_calls already launches an owned Mach-O under LLDB for bounded entry-call observations. Its stop/record/continue workflow is narrower than an analyst-controlled debugger session; preserve and reuse its applicable identity/cleanup semantics.
Process capture supplies finite terminal experiments, rather than a debugger's stopped-state register/memory/thread model.

Use cases

Correlate a static function or indirect call with the loaded module, ASLR-adjusted address and actual argument/return state.
Break on a selected instruction or exception, inspect registers, bytes, mappings and frames, then step or continue to test a hypothesis.
Use software breakpoints and supported hardware/data watchpoints to discover who modifies a selected buffer or field.
Follow module loading and thread/process events without mistaking a command acknowledgement for a completed stop.
Compare selected before/after memory or register observations, with explicit writes when an experiment requires them.
Reuse the same primitives for native applications, ABI reconstruction, crash diagnosis and firmware userspace analysis. CTF/crackme tasks are examples, not the public contract.

Desired outcome and success criteria

Shared analyst-facing behavior

Discover configured provider/version/architecture capabilities without launching a debugger or attaching a target during MCP startup.
Select an exact local executable/argv/environment/cwd, an existing process, or an existing debugger instance. Preserve their separate identities and ownership; a debugger PID is not the inferior PID or durable ownership proof.
Report actual running/stopped/exited/detached state, stop reason, thread/frame selection and a stop identity. Bind state observations to that stop; after resume, do not present an older snapshot as current.
Inspect registers, selected memory ranges, threads/frames, loaded modules and relevant instructions. Preserve exact address/byte/width/endianness facts, provider data, partial reads and explicit unknowns. Keep file offsets, module-relative offsets and runtime addresses distinct.
Set/list/change/remove selected breakpoints and supported watchpoints; report resolved locations, pending/unresolved status, condition semantics and actual hardware limitations.
Support explicit launch/attach, interrupt, step into/over/out, continue and detach/close outcomes. An accepted command and an observed stop are distinct facts; declare supported all-stop/non-stop/thread behavior.
Support selected memory/register writes as distinct operations with actual effects and readback. Expression evaluation, function calls and raw debugger commands can execute or mutate the target; expose their authority and retain the original request/transcript if offered.
Preserve target byte I/O separately from debugger protocol/console/log records, including NUL/non-UTF8 bytes. Support bounded event/output collection with meaningful completeness, dropped-event and resource-limit reporting.
Share application workflows through CLI/MCP, use named contracts and valid SDK-converted schemas, and return useful observations inline with Evidence, source locations and provider versions.

Provider research and reuse options

Provider / candidate	Verified interface or role	Proposed place in REA
GDB	Official MI has command results, asynchronous running/stopped/thread notifications and separate stream records; target async support is queried. GDB Python supports debugger-side extensions.	First headless Linux user-mode provider. Evaluate unchanged pygdbmi for existing controller/parser code instead of writing another MI grammar. Use a separate inferior I/O channel where required.
x64dbg / x32dbg	Current bridge exports command submission/direct execution, memory access, register dumps and breakpoint inventories; plugin callbacks cover breakpoints, steps, exceptions, process/thread/module lifecycle and attach/detach.	First Windows provider. Prefer an existing automation transport or plugin adapter over rebuilding the debugger or driving GUI pixels. Verify each bitness separately.
x64dbg Automate	Native plugin uses ZeroMQ request/reply and pub/sub with MessagePack; its reference Python client already exposes session/control/memory/register/breakpoint/event APIs and an MCP wrapper. Both repositories declare MIT.	Strong reuse candidate: compare its Python API and MCP surface against REA's identity, errors, Evidence and lifecycle requirements before choosing a transport. Its bounded event queues require an explicit completeness/drop policy.
LLDB	SBProcess/SBListener APIs expose state/events, memory and execution control; official `lldb-dap` provides launch/attach and debugger requests.	Subsequent Linux/macOS provider. Compare a small SB API bridge with DAP; probe optional DAP/native-register facets instead of assuming complete parity.
WinDbg / DbgEng	Microsoft documents standalone engine applications with breakpoints, events, symbols, memory and process/thread control; Pybag supplies Python bindings/helpers.	Windows alternative for an independently justified outcome. User-mode first; kernel debugging is separate scope.
pwndbg	GDB enrichment and experimental LLDB support, with backend/version prerequisites.	Optional context, pointer-chain or allocator facets. Basic debugging must work without it; extend the existing recorded-core adapter only where authority and meaning match.
rr	Linux execution recording/replay with reverse execution via GDB; CPU/performance-counter and VM constraints are documented.	Later, separate record/replay capability. An arbitrary VPS is not verified rr coverage.
Frida / DynamoRIO	Runtime instrumentation, hooks and tracing; their APIs answer different questions from a stopped debugger session.	Coordinate Frida with #968; consider instruction/basic-block tracing as independent facets when required. Do not duplicate either engine.
QEMU gdbstub / gdbserver	Debugger remote protocol can expose guest or separately hosted target state. QEMU documents accelerator-dependent breakpoint/watchpoint coverage.	Later explicitly selected target endpoints, coordinated with #718. Guest architecture/address spaces and native host debugging are different coverage claims.
Rizin / radare2	Existing command/API ecosystems and pipe interfaces provide additional integration candidates.	Evaluate for a concrete unmet debugger outcome; do not make several overlapping engines mandatory.

Existing MCP prior art: x64dbg Automate MCP, duty1g/x64dbg-mcp-server, and Wasdubya/x64dbgMCP expose existing debugger operations. Reuse an upstream adapter where it satisfies the required semantics; do not copy its whole tool inventory or assume its output/protocol/lifecycle contract matches REA. Source review is not runtime verification.

Suggested increments and real acceptance

Linux x64 GDB: BYO discovery, owned launch, typed state/register/memory observations, software breakpoints, step/continue/interrupt, target I/O and verified cleanup. Add existing-process attach/detach with an independently started fixture that must survive detach. Exercise CLI, actual stdio MCP and an isolated installed package.
Windows x64dbg: choose the automation/adapter path through a small compatibility experiment, then prove the same useful workflow with source-built PE fixtures and real x64dbg on Windows. Preserve caller-owned debugger instances; do not claim Linux/headless x64dbg from a cross-compiled plugin. Add x32dbg only with real x86 proof.
LLDB: establish the matching Linux/macOS workflow with SB API or DAP, separate OS attach-denial cases and real provider/version coverage.
Independent follow-ups: selected writes/watchpoints, richer exception/thread/module facts, optional pwndbg enrichment, event/instruction traces, rr replay and selected QEMU/gdbserver endpoints. Each increment needs an analyst outcome and corresponding real-provider lane.

Each applicable lane uses source-generated fixtures for known register/memory values, high addresses, ASLR/module reload, concurrent threads, delayed stops, missing symbols, unresolved breakpoints, partial/unmapped reads and genuine permission denial. Test cancellation while running, awaiting a stop and already stopped; timeout, malformed producer records, disconnect, event/output pressure and PID reuse. Verify original failure/stop outcomes and retained partial evidence independently of cleanup.

Deterministic protocol tests are useful but cannot replace real debugger claims. Keep prerequisites limited to each lane, bound CPU/memory/event/output retention, and explicitly report unverified host/target/architecture combinations.

Authority boundaries and non-goals

Debugging can pause/resume execution, patch bytes/registers and trigger the selected program's filesystem/network effects. Report actual effects. A selected operation expresses intent; do not add approval booleans or a separate grant system.
Reuse src/process/ supervision and start-identity primitives. Prove termination/cleanup for REA-owned launches; ordinary detach must preserve externally launched targets. Preserve collected observations even if cleanup fails, including paths and actionable diagnostics.
Bring-your-own debuggers/plugins and isolated bridge dependencies. Do not install/upgrade unrelated software, modify .gdbinit, ptrace/sysctl, system Python, host security settings or global debugger configuration. Use actual OS permissions and diagnose the failed constraint.
REA remains local-only. No automatically exposed network listener, remote service deployment or mandatory cloud account. A future caller-selected local debugger/guest endpoint does not authorize opening a public service; redact transport credentials while preserving caller-selected evidence.
Preserve unchanged upstream code, pin and record adapter/provider versions, and check the exact redistributed component licenses. x64dbg's GPL engine and MIT automation components are separate licensing surfaces.
Kernel/device debugging, anti-debug bypass, emulation/rehosting, reverse execution and automated exploit generation are outside the first user-mode increment. A custom orchestration/replay language is not needed for ordinary analyst commands and scripts.

Alternatives considered

Continue using static providers, existing bounded LLDB call observations and process capture when they already answer the question; add a live debugger only for the distinct state/control outcome.
Connect a standalone debugger MCP directly. Useful prior art, but it does not itself establish shared REA CLI semantics, Evidence provenance, exact identity or owned cleanup.
Scrape terminal prompts, GUI screens or idle output. These do not establish stop reasons or completed actions; use producer events and structured APIs where available.
Build a debugger core from scratch. Mature upstream engines already supply the difficult platform mechanisms.

Possible direction

Define a provider-neutral live-debugger port and small shared workflows for selected state inspection, breakpoints and execution actions. Keep MI, DAP, SB APIs, x64dbg transport and DbgEng inside provider/bridge modules. Reuse existing lifecycle and Evidence primitives, preserving provider-specific coverage instead of forcing an all-or-nothing common denominator.

The first design decision is which existing x64dbg interface to adapt and MI controller versus debugger-side GDB Python for the initial Linux workflow. Compare the smallest runnable paths against stop-state fidelity, exact byte I/O, cancellation, ownership, partial errors and resource use before committing to a transport. This issue specifies analyst outcomes, not final tool names or an implementation schedule.

References

REA: #32, #969, #968, #718, #717; native call observation, recorded crashes.
x64dbg bridge API, plugin callbacks. The old x64dbg_headless proof of concept is archived; it is not a supported headless deployment claim.
x64dbg Automate: event producer, session semantics, control and waits, bounded event queues.
Official GDB/MI manual, GDB Python API, pygdbmi, pwndbg backend/prerequisites.
LLDB: SBProcess API, SBListener API, official lldb-dap, DAP specification.
Microsoft debugger-engine overview, Pybag, rr requirements, QEMU gdbstub, Frida, DynamoRIO, Rizin, radare2.

Research status: GitHub issue history, upstream documentation, selected APIs/implementations and repository/license metadata reviewed through gh. No candidate live-debugger integration was executed or installed for this issue; documentation/API availability is not REA support proof. Implement later as focused, independently verifiable PRs after the current stability work.

Originally created by @N0zoM1z0 on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1267 ### Before submitting - [x] I searched open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Process capture or runtime observation ### Current limitation REA needs a reusable **live native debugging** workflow: select an executable or an existing process, stop at an analyst-selected location, inspect its actual state, step/resume, and use the observations to test a reverse-engineering hypothesis. Windows x64dbg and Linux GDB are the first intended providers; LLDB is another candidate for Linux/macOS. This is a deferred roadmap, opened at the owner's request so the work is not forgotten. **Current work remains bug fixes, stability and usability; this issue does not start implementation or a release.** Research baseline: REA main `552634d634655a722b2204cfbc4b29f6d442c294`, 2026-10-09. Parent: #32. Continue the live-debugger increment described in closed #969; its shipped offline ELF and recorded-core work remains complete. Coordinate native instrumentation with #968 and firmware/Android use cases with #718 / #717. Existing capabilities do not establish general live debugger control: - Ghidra/Hopper/IDA provide their own static/database analysis boundaries. - `inspect_recorded_crash` inspects historical crash evidence, with optional core-only GDB/pwndbg mapping context. - `observe_native_calls` already launches an owned Mach-O under LLDB for bounded entry-call observations. Its stop/record/continue workflow is narrower than an analyst-controlled debugger session; preserve and reuse its applicable identity/cleanup semantics. - Process capture supplies finite terminal experiments, rather than a debugger's stopped-state register/memory/thread model. ### Use cases - Correlate a static function or indirect call with the loaded module, ASLR-adjusted address and actual argument/return state. - Break on a selected instruction or exception, inspect registers, bytes, mappings and frames, then step or continue to test a hypothesis. - Use software breakpoints and supported hardware/data watchpoints to discover who modifies a selected buffer or field. - Follow module loading and thread/process events without mistaking a command acknowledgement for a completed stop. - Compare selected before/after memory or register observations, with explicit writes when an experiment requires them. - Reuse the same primitives for native applications, ABI reconstruction, crash diagnosis and firmware userspace analysis. CTF/crackme tasks are examples, not the public contract. ### Desired outcome and success criteria #### Shared analyst-facing behavior - [ ] Discover configured provider/version/architecture capabilities without launching a debugger or attaching a target during MCP startup. - [ ] Select an exact local executable/argv/environment/cwd, an existing process, or an existing debugger instance. Preserve their separate identities and ownership; a debugger PID is not the inferior PID or durable ownership proof. - [ ] Report actual running/stopped/exited/detached state, stop reason, thread/frame selection and a stop identity. Bind state observations to that stop; after resume, do not present an older snapshot as current. - [ ] Inspect registers, selected memory ranges, threads/frames, loaded modules and relevant instructions. Preserve exact address/byte/width/endianness facts, provider data, partial reads and explicit unknowns. Keep file offsets, module-relative offsets and runtime addresses distinct. - [ ] Set/list/change/remove selected breakpoints and supported watchpoints; report resolved locations, pending/unresolved status, condition semantics and actual hardware limitations. - [ ] Support explicit launch/attach, interrupt, step into/over/out, continue and detach/close outcomes. An accepted command and an observed stop are distinct facts; declare supported all-stop/non-stop/thread behavior. - [ ] Support selected memory/register writes as distinct operations with actual effects and readback. Expression evaluation, function calls and raw debugger commands can execute or mutate the target; expose their authority and retain the original request/transcript if offered. - [ ] Preserve target byte I/O separately from debugger protocol/console/log records, including NUL/non-UTF8 bytes. Support bounded event/output collection with meaningful completeness, dropped-event and resource-limit reporting. - [ ] Share application workflows through CLI/MCP, use named contracts and valid SDK-converted schemas, and return useful observations inline with Evidence, source locations and provider versions. #### Provider research and reuse options | Provider / candidate | Verified interface or role | Proposed place in REA | | --- | --- | --- | | **GDB** | Official MI has command results, asynchronous running/stopped/thread notifications and separate stream records; target async support is queried. GDB Python supports debugger-side extensions. | First headless Linux user-mode provider. Evaluate unchanged [pygdbmi](https://github.com/cs01/pygdbmi) for existing controller/parser code instead of writing another MI grammar. Use a separate inferior I/O channel where required. | | **x64dbg / x32dbg** | Current bridge exports command submission/direct execution, memory access, register dumps and breakpoint inventories; plugin callbacks cover breakpoints, steps, exceptions, process/thread/module lifecycle and attach/detach. | First Windows provider. Prefer an existing automation transport or plugin adapter over rebuilding the debugger or driving GUI pixels. Verify each bitness separately. | | **x64dbg Automate** | [Native plugin](https://github.com/dariushoule/x64dbg-automate) uses ZeroMQ request/reply and pub/sub with MessagePack; its [reference Python client](https://github.com/dariushoule/x64dbg-automate-pyclient) already exposes session/control/memory/register/breakpoint/event APIs and an MCP wrapper. Both repositories declare MIT. | Strong reuse candidate: compare its Python API and MCP surface against REA's identity, errors, Evidence and lifecycle requirements before choosing a transport. Its bounded event queues require an explicit completeness/drop policy. | | **LLDB** | SBProcess/SBListener APIs expose state/events, memory and execution control; official `lldb-dap` provides launch/attach and debugger requests. | Subsequent Linux/macOS provider. Compare a small SB API bridge with DAP; probe optional DAP/native-register facets instead of assuming complete parity. | | **WinDbg / DbgEng** | Microsoft documents standalone engine applications with breakpoints, events, symbols, memory and process/thread control; [Pybag](https://github.com/dshikashio/Pybag) supplies Python bindings/helpers. | Windows alternative for an independently justified outcome. User-mode first; kernel debugging is separate scope. | | **pwndbg** | GDB enrichment and experimental LLDB support, with backend/version prerequisites. | Optional context, pointer-chain or allocator facets. Basic debugging must work without it; extend the existing recorded-core adapter only where authority and meaning match. | | **rr** | Linux execution recording/replay with reverse execution via GDB; CPU/performance-counter and VM constraints are documented. | Later, separate record/replay capability. An arbitrary VPS is not verified rr coverage. | | **Frida / DynamoRIO** | Runtime instrumentation, hooks and tracing; their APIs answer different questions from a stopped debugger session. | Coordinate Frida with #968; consider instruction/basic-block tracing as independent facets when required. Do not duplicate either engine. | | **QEMU gdbstub / gdbserver** | Debugger remote protocol can expose guest or separately hosted target state. QEMU documents accelerator-dependent breakpoint/watchpoint coverage. | Later explicitly selected target endpoints, coordinated with #718. Guest architecture/address spaces and native host debugging are different coverage claims. | | **Rizin / radare2** | Existing command/API ecosystems and pipe interfaces provide additional integration candidates. | Evaluate for a concrete unmet debugger outcome; do not make several overlapping engines mandatory. | **Existing MCP prior art:** [x64dbg Automate MCP](https://github.com/dariushoule/x64dbg-automate-pyclient/blob/8807ff70509b1e6d785abbf9ee1e442c403b64bf/docs/mcp-server.md), [duty1g/x64dbg-mcp-server](https://github.com/duty1g/x64dbg-mcp-server), and [Wasdubya/x64dbgMCP](https://github.com/Wasdubya/x64dbgMCP) expose existing debugger operations. Reuse an upstream adapter where it satisfies the required semantics; do not copy its whole tool inventory or assume its output/protocol/lifecycle contract matches REA. Source review is not runtime verification. #### Suggested increments and real acceptance 1. **Linux x64 GDB:** BYO discovery, owned launch, typed state/register/memory observations, software breakpoints, step/continue/interrupt, target I/O and verified cleanup. Add existing-process attach/detach with an independently started fixture that must survive detach. Exercise CLI, actual stdio MCP and an isolated installed package. 2. **Windows x64dbg:** choose the automation/adapter path through a small compatibility experiment, then prove the same useful workflow with source-built PE fixtures and real x64dbg on Windows. Preserve caller-owned debugger instances; do not claim Linux/headless x64dbg from a cross-compiled plugin. Add x32dbg only with real x86 proof. 3. **LLDB:** establish the matching Linux/macOS workflow with SB API or DAP, separate OS attach-denial cases and real provider/version coverage. 4. **Independent follow-ups:** selected writes/watchpoints, richer exception/thread/module facts, optional pwndbg enrichment, event/instruction traces, rr replay and selected QEMU/gdbserver endpoints. Each increment needs an analyst outcome and corresponding real-provider lane. Each applicable lane uses source-generated fixtures for known register/memory values, high addresses, ASLR/module reload, concurrent threads, delayed stops, missing symbols, unresolved breakpoints, partial/unmapped reads and genuine permission denial. Test cancellation while running, awaiting a stop and already stopped; timeout, malformed producer records, disconnect, event/output pressure and PID reuse. Verify original failure/stop outcomes and retained partial evidence independently of cleanup. Deterministic protocol tests are useful but cannot replace real debugger claims. Keep prerequisites limited to each lane, bound CPU/memory/event/output retention, and explicitly report unverified host/target/architecture combinations. ### Authority boundaries and non-goals - Debugging can pause/resume execution, patch bytes/registers and trigger the selected program's filesystem/network effects. Report actual effects. A selected operation expresses intent; do not add approval booleans or a separate grant system. - Reuse `src/process/` supervision and start-identity primitives. Prove termination/cleanup for REA-owned launches; ordinary detach must preserve externally launched targets. Preserve collected observations even if cleanup fails, including paths and actionable diagnostics. - Bring-your-own debuggers/plugins and isolated bridge dependencies. Do not install/upgrade unrelated software, modify `.gdbinit`, ptrace/sysctl, system Python, host security settings or global debugger configuration. Use actual OS permissions and diagnose the failed constraint. - REA remains local-only. No automatically exposed network listener, remote service deployment or mandatory cloud account. A future caller-selected local debugger/guest endpoint does not authorize opening a public service; redact transport credentials while preserving caller-selected evidence. - Preserve unchanged upstream code, pin and record adapter/provider versions, and check the exact redistributed component licenses. x64dbg's GPL engine and MIT automation components are separate licensing surfaces. - Kernel/device debugging, anti-debug bypass, emulation/rehosting, reverse execution and automated exploit generation are outside the first user-mode increment. A custom orchestration/replay language is not needed for ordinary analyst commands and scripts. ### Alternatives considered - Continue using static providers, existing bounded LLDB call observations and process capture when they already answer the question; add a live debugger only for the distinct state/control outcome. - Connect a standalone debugger MCP directly. Useful prior art, but it does not itself establish shared REA CLI semantics, Evidence provenance, exact identity or owned cleanup. - Scrape terminal prompts, GUI screens or idle output. These do not establish stop reasons or completed actions; use producer events and structured APIs where available. - Build a debugger core from scratch. Mature upstream engines already supply the difficult platform mechanisms. ### Possible direction Define a provider-neutral live-debugger port and small shared workflows for selected state inspection, breakpoints and execution actions. Keep MI, DAP, SB APIs, x64dbg transport and DbgEng inside provider/bridge modules. Reuse existing lifecycle and Evidence primitives, preserving provider-specific coverage instead of forcing an all-or-nothing common denominator. The first design decision is **which existing x64dbg interface to adapt** and **MI controller versus debugger-side GDB Python for the initial Linux workflow**. Compare the smallest runnable paths against stop-state fidelity, exact byte I/O, cancellation, ownership, partial errors and resource use before committing to a transport. This issue specifies analyst outcomes, not final tool names or an implementation schedule. ### References - REA: #32, #969, #968, #718, #717; [native call observation](https://github.com/morluto/rea/blob/552634d634655a722b2204cfbc4b29f6d442c294/docs/native-investigation.md#native-call-observation), [recorded crashes](https://github.com/morluto/rea/blob/552634d634655a722b2204cfbc4b29f6d442c294/docs/recorded-crashes.md). - [x64dbg bridge API](https://github.com/x64dbg/x64dbg/blob/4c8dcc17bcf6eca287da51fbb601510da3336e13/src/bridge/bridgemain.h), [plugin callbacks](https://github.com/x64dbg/x64dbg/blob/4c8dcc17bcf6eca287da51fbb601510da3336e13/src/dbg/_plugins.h). The old [x64dbg_headless proof of concept](https://github.com/x64dbg/x64dbg_headless) is archived; it is not a supported headless deployment claim. - x64dbg Automate: [event producer](https://github.com/dariushoule/x64dbg-automate/blob/76421a901499fb22846127b0cba6b7c4de0ab850/src/plugin.cpp), [session semantics](https://github.com/dariushoule/x64dbg-automate-pyclient/blob/8807ff70509b1e6d785abbf9ee1e442c403b64bf/docs/api/session-control.md), [control and waits](https://github.com/dariushoule/x64dbg-automate-pyclient/blob/8807ff70509b1e6d785abbf9ee1e442c403b64bf/docs/api/debug-control.md), [bounded event queues](https://github.com/dariushoule/x64dbg-automate-pyclient/blob/8807ff70509b1e6d785abbf9ee1e442c403b64bf/x64dbg_automate/events.py). - [Official GDB/MI manual](https://sourceware.org/gdb/current/onlinedocs/gdb.html/GDB_002fMI.html), [GDB Python API](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Python-API.html), [pygdbmi](https://github.com/cs01/pygdbmi), [pwndbg backend/prerequisites](https://github.com/pwndbg/pwndbg). - LLDB: [SBProcess API](https://github.com/llvm/llvm-project/blob/ed4aed21f36b4afc0bfbbd04d1e0b7177edbd33a/lldb/include/lldb/API/SBProcess.h), [SBListener API](https://github.com/llvm/llvm-project/blob/ed4aed21f36b4afc0bfbbd04d1e0b7177edbd33a/lldb/include/lldb/API/SBListener.h), [official lldb-dap](https://github.com/llvm/llvm-project/blob/ed4aed21f36b4afc0bfbbd04d1e0b7177edbd33a/lldb/tools/lldb-dap/README.md), [DAP specification](https://github.com/microsoft/debug-adapter-protocol/blob/main/specification.md). - [Microsoft debugger-engine overview](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-engine-overview), [Pybag](https://github.com/dshikashio/Pybag), [rr requirements](https://github.com/rr-debugger/rr), [QEMU gdbstub](https://github.com/qemu/qemu/blob/9f9f41d837394aa96232ee03137d90d24658563a/docs/system/gdb.rst), [Frida](https://github.com/frida/frida), [DynamoRIO](https://github.com/DynamoRIO/dynamorio), [Rizin](https://github.com/rizinorg/rizin), [radare2](https://github.com/radareorg/radare2). **Research status:** GitHub issue history, upstream documentation, selected APIs/implementations and repository/license metadata reviewed through `gh`. No candidate live-debugger integration was executed or installed for this issue; documentation/API availability is not REA support proof. Implement later as focused, independently verifiable PRs after the current stability work.

bsakaguchi added the

labels

2026-10-15 18:25:12 +00:00

bsakaguchi commented

2026-10-15 18:25:13 +00:00

Author