Repository navigation
Conversation
There was a problem hiding this comment.
Review: synthetic debug location fix
This is a clean, well-scoped fix. All debug-location writes in the ssa package now flow through the new setDebugLocation helper, keeping the tracked diLocation field in sync with the LLVM builder. Synthetic builders created after DebugFunction get a line-zero, function-scoped location — the correct DWARF convention for compiler-generated code — which satisfies LLVM's requirement that inlinable calls carry a !dbg location. Switching deferInitBuilder to read the tracked field instead of GetCurrentDebugLocation() also removes a CGO round-trip.
Verified:
- All
SetCurrentDebugLocationcall sites route throughsetDebugLocation, sodiLocationcannot silently desync today. Builder = *aBuilder, sob.diLocation = locmutates the shared struct as intended.TestSyntheticBuilderDebugLocationcovers the three meaningful orderings (before debug init, after debug init, without debug) and asserts the line-zero-in-function-scope invariant plus module verification.
No correctness, security, or performance concerns found. Two minor, non-blocking maintainability notes are inline. (go vet/build could not be run here — the LLVM C headers are unavailable in this environment.)
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
9ccd23c to
4d3883b
Compare
LLGo WebAssembly build benchmarks
WebAssembly output sizes
LLGo WebAssembly build measurements
Compared with |
LLGo baseline benchmarks
Program measurements
Core language and compiler benchmarks
Timer runtime benchmarks
Compared with |
Problem
Synthetic builders may not have a current source location even when their function has a DISubprogram. The LLVM binding explicitly requires a location to have been set before calling
GetCurrentDebugLocation;deferInitBuilderviolated that precondition and crashed inLLVMGoGetCurrentDebugLocationduring CI.Other synthetic calls in debug-enabled functions failed LLVM verification: an inlinable call must have a
!dbglocation. The expanded macOS LTO checks exposed this foros.(*root).decref. The affected code exists on upstream mainbe23e488a; this PR contains no unrelated runtime changes.Fix
Validation
This contribution replaces fork PR cpunion/llgo#245. Per request, the remaining fork CI is cancelled and verification continues in this upstream PR; the fork CI is not claimed as passing. No debug-info disabling or LLVM dependency replacement is used.
Why earlier CI did not expose this
The affected path needs debug metadata plus a synthetic builder that either has no current location or emits an inlinable generated call checked by LLVM verification/LTO. Earlier completed WASM startup and release lanes did not combine those conditions, and shallower compilation failures could stop before this verifier path. The new tests construct the missing-location states directly and verify the generated LLVM module, making the invariant independent of a particular target matrix.
CI, coverage, and diff audit (2026-09-11)
At head
85854a71c, all existing non-skipped checks pass, including the platform/Wasm tests and benchmark matrix. Codecov patch coverage is 100.00% of the measured diff, not merely an upload-action success. These are results for this exact head; a later rebase still requires new validation.The 5-file diff is limited to debug-location state, initialization/restoration, and tests. Both review requests are implemented. No debug-info disabling or new test exclusion was added.
Size audit of the benchmark artifacts against each artifact's recorded base: All recorded Wasm module/glue sizes and Linux cprintf/println/fmtprintf size metrics, including LTO variants, are unchanged.
Performance follow-up: TimerRearmStopped measured 2,609 → 3,425 ns/op (+31.3%, five samples) in this run. A controlled repeat is still needed before attributing that timing difference to the debug-location change.
The Wasm benchmark results recorded above cover
printlnonly. cpunion/llgo#247 addscprintf/fmtprintfbuild and size measurements; those measurements do not establish runtime throughput or independent Go-compatible JavaScript provider acceptance. Native results above must not be read as Wasm measurements. No blanket performance-completion claim is made here.