Joseph Ferano
201cd87bc9
--x86 --debug was refused in build.ml for want of DWARF. It emits it now: a compile unit, a subprogram per function, and a line table, so gdb breaks by Flan file and line and a backtrace names Flan source. The reason it is written as data rather than as .loc directives is the finding worth carrying forward, and HANDOFF-x86-debug.md leads with it. GAS builds its line table out of dwarf2_emit_insn, which runs only when an instruction is assembled, and this backend assembles none -- everything is a .byte blob. A pending .loc therefore sits until the next .loc and is flushed at whatever the location counter has reached by then: every row comes out one statement late and the last statement of every function gets no row at all. Measured on GAS 2.44, and interposing labels does not help. So .debug_line is emitted here the way the instructions are. Every row is a full DW_LNE_set_address on a label rather than an advance_pc with a computed delta, because a delta would be a difference of two labels inside a .uleb128 -- a value whose size changes the offsets after it, and whose failure would look exactly like a DWARF bug. The .file 1 directive at the top of the assembly is not about our table at all: without it clang's integrated assembler generates a compile unit of its own over the .s, whose rows land at the call mnemonics, and those addresses are inside the functions we already describe. -gdwarf-4 goes with it so the empty stub it leaves behind parses. Rows are deduplicated on the byte counter as well as on the position. lower recurses, so an outer form and the inner one that emits its first byte both ask for a row at the same address; keeping the first is smaller and is the better answer, since a debugger takes the last of a run. buf.n already existed and was written but never read. This is its first reader. No locals and no types, deliberately. A slot here is a bump-allocated frame temporary whose offset is known but whose lifetime is not modelled -- scoped reclaims temporaries and a later expression reuses the bytes -- so a DW_TAG_variable would be right at some addresses and confidently wrong at others. That is the call build.ml already makes about wasm32's member offsets. Verified under gdb against test/programs/debug.flan, and against an LLVM --debug build of the same program. Identical bar the parameter values, which is the locals work. Transcript in the handoff.
