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

[mailinglists at geldenhuys.co.uk]

On 2026-02-20 15:53, Hairy Pixels via fpc-devel wrote:
>  is there anything wrong with DWARF for Pascal?

Yes and no. DWARF itself is not broken -- it is a well-designed,
mature standard. The problem is that DWARF was designed for
procedural/C-centric languages, and Object Pascal concepts do not map
naturally onto it. Some specific issues:

- Properties: DWARF has no native concept of getter/setter accessor
methods as a language construct. Noted that DWARF 5 added property
support, but FPC currently generates DWARF 2/3 (with partial DWARF 4),
and even with DWARF 5 the encoding is a workaround rather than a
native representation. GDB and LLDB still struggle with reliably
calling Pascal methods to evaluate property getters during a debug
session.

- String types: ShortString, AnsiString, and UnicodeString are all
reference-counted heap-allocated strings with metadata (code page,
reference count, length). DWARF represents these as raw byte arrays or
PChar, losing the semantic meaning. fpdebug works around this by
reverse-engineering FPC's DWARF quirks, but this is fragile and
version-dependent.

- Sets: DWARF stores sets as raw bytes with no type information
linking the bitfield back to the underlying enumeration members. A
debugger shows you a numeric value instead of [Mon, Tue, Wed].

- Dynamic arrays: Display incorrectly or without correct length
information, since the metadata (high value stored at a negative
offset from the data pointer) is an FPC implementation detail that
DWARF does not describe.

So it is partly how FPC implements DWARF, but also partly that DWARF
simply does not have vocabulary for these Pascal concepts. fpdebug has
made heroic efforts to work around these limitations by interpreting
FPC-specific DWARF patterns, but every workaround is another piece of
fragile, version-coupled code.


Regards,
   Graeme