JosephFerano/flan
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

A frame with no line does not get the wrong line

Browse Source 
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.
This commit is contained in:
Joseph Ferano 2026-09-13 23:43:41 +07:00
parent ae1b113ad4
commit a9c5cf0c26
1 changed files with 22 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
HANDOFF-x86-debug.md
View File

@ -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