[GH-ISSUE #2382] [Feature] Retain LLDB source coordinates for observed native call locations #793

New issue

Open

opened 2026-10-15 18:28:25 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:28:25 +00:00

Owner

Originally created by @matbrgz on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2382

Analyst question

For a native call entry already observed by REA, which compiler-provided source file, line and column does LLDB associate with its exact code location?

Current nativeCodeLocation retains module, symbol and load/file addresses but discards LLDB line-entry metadata. This also limits source-built Pascal/Delphi investigations where supported symbols are available.

Proposed change

Add optional, nullable source-location evidence to resolved breakpoint locations, observed entries and caller frames. The producer reads SBAddress.GetLineEntry while it already owns the stopped observation. Preserve file path, positive line and available column; absent/invalid line entries remain unavailable.

Preserve the existing location fields and historical evidence. Do not read source file contents, evaluate expressions, launch additional targets or claim that an emitted path verifies the bytes of a source file. Line-table attribution is separate from executable source-file association.

Acceptance

Fake-LLDB boundary tests cover valid/invalid file and line entries, missing columns and non-ASCII paths.
Existing captures that omit the new field remain readable.
Breakpoint, event and backtrace results retain the same canonical source shape through public contracts.
An owned C fixture with debug info verifies the actual LLDB path on an available macOS host; Pascal/Delphi support is not inferred from that fixture.
Missing debug metadata remains explicit without changing existing capture outcomes.
One native-call source-location spec/plan precedes implementation.

Scope and references

An additive observation within the existing bounded macOS LLDB lane, not a new debugger/session provider. New Pascal (#2372), Delphi (#2375) and general debugger (#1267) capabilities remain independently scoped.

Originally created by @matbrgz on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2382 [![Type: Feature](https://img.shields.io/badge/type-feature-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Domain: AI & Runtimes](https://img.shields.io/badge/domain-AI_&_runtimes-blueviolet.svg?style=flat-square)](https://github.com/morluto/rea) [![Status: Proposed](https://img.shields.io/badge/status-proposed-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Ecosystem: REA](https://img.shields.io/badge/ecosystem-morluto%2Frea-8A2BE2.svg?style=flat-square)](https://github.com/morluto/rea) ## Analyst question For a native call entry already observed by REA, which compiler-provided source file, line and column does LLDB associate with its exact code location? Current nativeCodeLocation retains module, symbol and load/file addresses but discards LLDB line-entry metadata. This also limits source-built Pascal/Delphi investigations where supported symbols are available. ## Proposed change Add optional, nullable source-location evidence to resolved breakpoint locations, observed entries and caller frames. The producer reads SBAddress.GetLineEntry while it already owns the stopped observation. Preserve file path, positive line and available column; absent/invalid line entries remain unavailable. Preserve the existing location fields and historical evidence. Do not read source file contents, evaluate expressions, launch additional targets or claim that an emitted path verifies the bytes of a source file. Line-table attribution is separate from executable source-file association. ## Acceptance - [ ] Fake-LLDB boundary tests cover valid/invalid file and line entries, missing columns and non-ASCII paths. - [ ] Existing captures that omit the new field remain readable. - [ ] Breakpoint, event and backtrace results retain the same canonical source shape through public contracts. - [ ] An owned C fixture with debug info verifies the actual LLDB path on an available macOS host; Pascal/Delphi support is not inferred from that fixture. - [ ] Missing debug metadata remains explicit without changing existing capture outcomes. - [ ] One native-call source-location spec/plan precedes implementation. ## Scope and references An additive observation within the existing bounded macOS LLDB lane, not a new debugger/session provider. New Pascal (#2372), Delphi (#2375) and general debugger (#1267) capabilities remain independently scoped. - [LLDB SBAddress.GetLineEntry](https://lldb.llvm.org/python_api/lldb.SBAddress.html) - [LLDB SBLineEntry](https://lldb.llvm.org/python_api/lldb.SBLineEntry.html)

bsakaguchi added the

area: native

enhancement

P2: medium

labels

2026-10-15 18:28:25 +00:00

bsakaguchi commented

2026-10-15 18:28:26 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Implementation & Linkage Status Update

Summary (ELI5):
Retain original source file paths, line numbers, and column offsets for function entry points and native call-path steps observed during LLDB debugger sessions.

Current State & Dependencies:

Implemented in PR #2400 (feat(native): retain LLDB source coordinates and verify Pascal call entries).
Producer and boundary tests pass (10 Python producer tests, 18 focused native MCP tests).
Blocked on investigating the flaky launch-identity and event-limit verifier failure observed under macOS arm64 (#2397). PR #2400 will remain in draft until #2397 confirms whether upstream LLDB verifier timing or process generation caused the regression.

@matbrgz commented on GitHub (Oct 12, 2026): ### Implementation & Linkage Status Update **Summary (ELI5):** Retain original source file paths, line numbers, and column offsets for function entry points and native call-path steps observed during LLDB debugger sessions. **Current State & Dependencies:** - Implemented in PR #2400 (`feat(native): retain LLDB source coordinates and verify Pascal call entries`). - Producer and boundary tests pass (10 Python producer tests, 18 focused native MCP tests). - Blocked on investigating the flaky launch-identity and event-limit verifier failure observed under macOS arm64 (#2397). PR #2400 will remain in draft until #2397 confirms whether upstream LLDB verifier timing or process generation caused the regression.

bsakaguchi referenced this issue

2026-10-15 18:28:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-17 21:07:00 +00:00

[PR #933] [MERGED] fix(setup): accept the pinned Hopper RPM launcher #2510

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:37 +00:00