On 2026-02-20 17:19, Martin Frb via fpc-devel wrote:
The biggest sore with DWARF that I was aware of was properties. But they have been added to the DWARF standard (including indexed and more).
ps: apologies for the wall of text ;-) You are correct that many of these issues could theoretically be addressed within DWARF. FPC could emit better DWARF, fpdebug could interpret it more thoroughly, and the DWARF standard does continue to evolve. However, there is a practical reality: every Pascal concept that DWARF does not natively represent requires a custom encoding convention, a corresponding interpretation in the debugger, and ongoing maintenance as both FPC and the DWARF standard evolve. Properties, managed types, sets, variant records, nested procedure scoping — each one is a separate workaround layered on top of a format designed for C. The scoping example is illustrative. You noted that FPC does not currently emit the information that a variable declared after a nested procedure is not visible to that procedure. I implemented this in OPDF, in just a few minutes, with a simple DeclIndex field -- a 2-byte addition to two record types. In DWARF, this would require either extending DW_AT_start_scope usage (which GDB and LLDB interpret inconsistently) or inventing a custom attribute, then teaching fpdebug to interpret it. The OPDF approach took a a few minutes; the DWARF approach would require navigating compatibility constraints with multiple debugger frontends. The question is not whether it is possible to encode Pascal semantics in DWARF, but whether it is the best use of limited development resources. Borland/Embarcadero faced the same decision and chose a custom format (TD32, later PDB hybrid). The result was a superior debugging experience that the DWARF-based open source toolchains have never matched.
I don't know what the new format does in terms of calling params, and stack resolution....
OPDF currently handles local variables, function parameters, and stack frame resolution. Each local variable and parameter record includes a ScopeID (linking it to a function scope), a LocationExpr (location expression type -- RBP-relative for stack variables, with parent-frame chain support for nested procedures), and a LocationData field (the stack offset). Function scope records define the address range (LowPC/HighPC) for each function. The debugger uses this to resolve stack frames, evaluate local variables at any point in the call stack, and navigate the callstack with full symbol resolution. We recently tested this on a 93-unit real-world application and successfully resolved callstacks 19 frames deep with correct local variable access. You are right that DWARF provides richer expression evaluation capabilities (the DWARF expression machine is essentially a stack-based virtual machine). OPDF's current approach is simpler and covers the common cases. More complex location expressions can be added as needed -- but the advantage is that we add them in direct response to Pascal debugging needs, not as workarounds within a C-centric specification. The broader point: OPDF is not about what DWARF cannot do -- it is about the cost of continuously encoding Pascal semantics into a format that was not designed for them, versus investing in a format that represents them natively. Finally, on a personal note -- OPDF grew out of the same kind of curiosity that led me to create fpGUI Toolkit. With fpGUI, I wanted to understand how GUI frameworks worked from the ground up, so I built one. When Duby was released, it sparked a similar curiosity about how debuggers work internally. OPDF and the PDR debugger are the fruit of that exploration -- a desire to understand the full stack, from compiler-emitted debug records through to variable evaluation in a running process. Hopefully after I make the Pull Request public [soon] and share my documentation, it will all make more sense. Regards, Graeme _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
