debugger: debug native programs #42
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Section 4 describes debugging a native build.
Source
Acceptance criteria
Dependencies
None known.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). Implements DEBUGGER.md section 20 / section 4 (debugging a native build); the design record is the specification, no collision with CONCEPT "Open Questions". Touches the native back end and debugger; the acceptance criterion is a single line and will need testable slices, plus a platform question for CI, settled in refine. next: refine (queued)
[loop:torbscript] refine: still queued behind the intake order. next: waiting (ready buffer full: #4, #163, #164, #223 are ready) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261023 until 2026-10-23T03:39:59Z
[loop:torbscript] decided by the loop: #42 is an epic and gets no
readyitself. Section 4 plus the C back end (a#lineper block only,Statementignored bybackend/c/body.trb,torb buildnever lowers for debugging,-gonly through the profile'sdebugInformation) make four steps; each is one PR, the next is filed only when the previous lands:#lineper statement of a debugged lowering,torb build --debug(-O0 -g), DWARF line-table gate (ready)torb_text,torb_list,torb_mapand the program's layoutstorb debuglauncheslldb-daporgdb --interpreter=dapfor a native program, translatess12_counttocountinvariables; a session intests/debug/torb-debug.md, editor guide) and the VS Code launch for a native program; DEBUGGER.md sections 4, 18, 20Why these decisions: the design record fixes the options (section 4 chose gdb/lldb behind DAP, not a second adapter), so no owner question. Adapter choice for step 3:
lldb-dapif found, elsegdb --interpreter=dap(gdb 14+); the CI gate runs on linux-x64 only and is measured first (is a debugger installed on the runner image; if not, the image gains it in a PR of its own, no runner change). Platform scope: the debugger session test is linux-x64; macOS and Windows are checked by the line-table gate only. Ordering: independent of #403 (task threads) and #39 (evaluate); all three touch DEBUGGER.md sections 18/20, so rebase after whichever lands first. #40 (stdin) is closed and landed.This epic is waiting on its steps. next: waiting (#405 in implementation)
[loop:torbscript] refine: split into steps, #405 is ready. Tokens used for this refine: about 90k. next: waiting (epic waits on its steps, #405 first)
[loop:torbscript] claim refine by session:loop-torbscript-20261024 until 2026-10-24T09:10:00Z
[loop:torbscript] decided by the loop: step 1 (#405) landed on main (PR #408, merge commit
2442b1c45, DEBUGGER.md slice 7 Done,tools/debug-lines.shpresent). The epic's remaining list is re-cut: step 2 = layout table the emitter writes plus the gdb (Python) pretty printers (#469); the lldb formatters move to their own step 3 because they reuse the same table and one PR with both would exceed two commits; thentorb debugfor a native program; then docs and editor launch. Why: the design record fixes the options (section 4), so no owner question; gdb first because its Python API is scriptable in a batch gate, and whether gdb is on the CI runner image is measured in the PR, not asked.[loop:torbscript] refine: step 2 filed as #469 and marked ready, next: waiting (epic waits on its steps, #469 next). Tokens used: about 60k
[loop:torbscript] refine: step 2 (#469, PR #471) merged 2026-10-24; step 3 filed as #600 (lldb formatters, ready), next: waiting (epic waits on its steps, #600 next)
[loop:torbscript] refine: re-checked 2026-10-29T17:56Z: step 3 (#600) is claimed by an implementer and PR #601 is open. Nothing else to do on the epic.
next: waiting (epic; step 3 is #600, PR #601 in review)