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

[Martin Frb]

On 21/02/2026 17:34, Graeme Geldenhuys via fpc-devel wrote:
>
> - 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.

I was referring to DWARF 6.
https://dwarfstd.org/issues/240507.1.html

And yes, its not out yet, but that needn't stop us from using it.

>
> - 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.
Yes, strings need something better. But that could be added.

Also, dwarf allows custom tags.


>
> - 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].
What am I missing here that makes this the fault of DWARF?
With the link to the enum, all the info is there (FpDebug certainly has 
the info, and shows it / and does so without hacks).

So if any debugger does not, then isn't that a problem of that debugger? 
And not a problem of Dwarf?

> - 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.
Actually it does. location expressions (or some other expression).
The bounds can be an expression, and the bounds can be anywhere in 
memory, or a constant.

What isn't avail is the refcount => Which is normally not needed to 
debug user code. Only if the compiler generates bad code, and one debugs 
internals of the data handled by the compiler, then that is needed.


>
> So it is partly how FPC implements DWARF, but also partly that DWARF
> simply does not have vocabulary for these Pascal concepts. 

Strings are the biggest issue. Especially when fpc follows Delphi with 
zero based index as option....

IIRC DWARF 4 has some string type, but I don't know if that applies at 
all, and it doesn't cover the whole set of possibilities.

But then again, submitting to DWARF is easy.
What it really needs is for someone to implement it into FPC.
(But then for a completely new format, that is the same, only that you 
volunteered as the someone, creating that advantage for your format)