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 _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
