From a9c5cf0c26190d2c6f00c3b1d29c302948381985 Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sun, 13 Sep 2026 23:43:41 +0700 Subject: [PATCH] A frame with no line does not get the wrong line flan..init-globals and the C main shim sit inside the compile unit's range and have no line-table sequence. The worry is that a debugger picks a row out of a neighbouring function's sequence and reports a confident wrong Flan line; it does not. Checked by breaking inside dev-globals.flan's initialiser: the frame is named from the ELF symbol, the line is honestly absent, and the unwind out to libc is the .cfi working. So that handoff item is a gap and not a wrong answer, which is worth the distinction because the two deserve different urgency. --- HANDOFF-x86-debug.md | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/HANDOFF-x86-debug.md b/HANDOFF-x86-debug.md index 2c665c4..ae23b53 100644 --- a/HANDOFF-x86-debug.md +++ b/HANDOFF-x86-debug.md @@ -196,8 +196,10 @@ Breakpoint 1, flan_bounds_error (loc=0x40a880 "test/programs/bounds.flan:11:44", `.text` — ends at 0x400bc1 + 0x36 = 0x400bf7. So `.Ldwtext` / `.Ldwtext_end` bracket the four functions this unit emitted and nothing else. -`--x86 --dev --debug` together, which is a reachable combination and was never exercised by anything else, -builds, runs and gives a line table `readelf` reads with no warnings. +`--x86 --dev --debug` together, which is a reachable combination and is exercised by nothing else, builds, +runs, and gives a line table and an `.eh_frame` that `readelf` reads with no warnings — 280 FDEs, ours among +the runtime's. That is the one combination where the cells' `.data`, the `.eh_frame` and the debug sections +all have to be ordered against each other. Cross-checked on a spread of the corpus — `debug`, `generics`, `vec`, `maps`, `strings`, `conditions`, `bounds-condition`, `algorithms`, `handles`, `registry`, `destructure`, `edn`, twelve in all — every one @@ -254,10 +256,24 @@ while the run still exits 0. bodies have no lines. Nothing reaches that yet — `flan dev` does not build `--x86` at all (`HANDOFF-x86-redef.md` §"What remains" item 3) — but when it does, a break loop stopping in a reloaded body will show raw addresses. -4. **`emit_main` and `flan..init-globals` have no rows.** They are inside the compile unit's `low_pc` / - `high_pc` range, which is honest — a debugger finds no line for an address in them and says so — but a - backtrace through the globals' initialiser names nothing. `emit_globals_init` does lower expressions that - carry locations, so this is a small piece of work: give it a `dwsub` the way `emit_fn` has one. +4. **`emit_main` and `flan..init-globals` have no rows, and this is a gap rather than a wrong answer.** + Both sit inside the compile unit's `low_pc` / `high_pc` range and neither has a line-table sequence, so + the worry is that a debugger picks a nearby row out of a *neighbouring* function's sequence and reports a + confident wrong Flan line. It does not. Checked, breaking inside the initialiser of `dev-globals.flan` + built `--x86 --debug`: + + ``` + Breakpoint 1, 0x0000000000400cec in flan..init-globals () + #0 0x0000000000400cec in flan..init-globals () + #1 0x00007ffff7cb96a4 in __libc_start_main_impl () from /lib64/libc.so.6 + #2 0x00000000004006c5 in _start () + No line number information available. + ``` + + The frame is named from the ELF symbol, the line is honestly absent, and the unwind out to libc is the + `.cfi` working. So this is worth doing and is not urgent: `emit_globals_init` does lower expressions that + carry locations, and giving it a `dwsub` the way `emit_fn` has one is the whole of it — it already takes + `~cfi`, so `?dw` goes in beside it. 5. **`debug-permuted.flan` has no `--x86` arm.** The new acceptance case covers `debug.flan` only. The permuted fixture exists to catch a member offset that does not follow the declaration, and that is a *types* claim — there are no type DIEs here to get wrong, so it would test nothing today. It becomes the