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

[Martin Frb]

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

Actually, as I said, defining a local var in the nested proc with 
location expression. Nothing custom.
Amount of work I can't compare, don't know yours. But also can't 
estimate how much it would be for someone who has comparable knowledge 
on FPC *AND* DWARF.
(I.e. for me to add to your code, would be considerable more work, 
because I wouldn’t have the background knowledge / so comparisons aren't 
that simple)

Saying "Gdb/lldb" wont understand is a bit of a strange argument. Will 
they understand your new format?


>
> 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.

But, adding an extra debug info format, and maintain BOTH will require 
even more resources. I would assume...

And a complete switch would mean that there needs to be a debugger for 
the new format that can handle all architectures 
(intel/arm/amiga/embedded/...)
And assume that no one wants to use gdb for reverse stepping (or 
implement that too).

I'd say, having such a debugger would be cool....
But, even then, there are people who step into kernel, or dll => those 
have dwarf debug info => so the new debugger needs to be able to 
understand both.

I am not trying to in any way "oppose" your effort. Haven't even seen it 
yet. More choice is going to be nice.
But your reasoning so for, sorry but some of the arguments against dwarf 
do not stand.



>  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 have much background on that. But isn't that a decision from a 
very long time ago? Back when dwarf was way less than today.

But also, yes rolling your own you can go shortcuts save some 
work/money, by being less generic, and only cover what you need.
Again that ends when apps step into libraries and kernel.  To support 
that, then suddenly means twice the work.

And of course doing there own, on closed source may give them extra 
control over their clients....


>
> 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.

That is a different point from many of your previous statements.

How, then do you solve stepping into kernel, or libraries (that have 
dwarf debug info, and aren't written in Pascal)?
Well, yes, you still save on **encoding** Pascal into Dwarf. But you 
have to decode 2 debug formats. (or more, depending on which others you 
want to support, in any case: 1 more than otherwise)


>
> 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.

That is understandable.

My earlier point on "stack resolution" wasn't fully answered though.

How to you encode: How to find the address of the parent stack frame?
This may not be in the RBP register at all times.
Some functions don't even have a frame.
And, when entering a function then the frame isn't set up yet.
So finding the parent needs debug info too.

Dwarf has some info there, but of course a debugger then needs even 
more, as it may have to resolve through parts that don't have debug info 
(callbacks going through the kernel), but when going enough frames there 
will be further frames with debug info.
(gdb still beats fpdebug in some cases... argh).