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