[fpc-devel] A little something I've been working on...

[mailinglists at geldenhuys.co.uk]

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