<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 20/02/2026 16:53, Hairy Pixels via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGsUGtkVWbNTG7XM=15vqmYCvEt3xcwbgnnfh-ef9FC7d1YD5g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Feb 20, 2026 at 7:02:09 PM,
Graeme Geldenhuys via fpc-devel <<a
href="mailto:fpc-devel@lists.freepascal.org"
moz-do-not-send="true" class="moz-txt-link-freetext">fpc-devel@lists.freepascal.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"
type="cite">
<div>What is it? A fully working, native FPC debug format and
debugger. I <br>
designed a new debug format from scratch (ditching the very
C-centric <br>
DWARF format and its many versions) and added support into
FPC `main` <br>
(3.3.1) via a feature branch. That's all on the compiler
side.<br>
</div>
</blockquote>
</div>
<br>
<div dir="ltr"> is there anything wrong with DWARF for Pascal? I
use LLDB on macOS and there's some things I'd like improved but
I figured that just due to how FPC implemented it and not the
format itself.</div>
<br>
</blockquote>
<br>
The biggest sore with DWARF that I was aware of was properties. But
they have been added to the DWARF standard (including indexed and
more).<br>
<br>
Well, there is also "managed types" that are absent => that is
needed, if such data should be modified by the debugger.<br>
<br>
One could argue, that there also is the lack of many scoping rules
for Pascal....<br>
But, partly that lack is caused by stuff not provide by FPC, which
would be possible, and in other parts it would be of very limited
help.<br>
<br>
------<br>
<br>
E.g. currently <br>
<br>
procedure foo;<br>
var SeenByBar: byte;<br>
procedure Bar;<br>
begin {} end;<br>
var NOT_SeenByBar: byte;<br>
begin {} end;<br>
<br>
FPC currently does not include the info that the 2nd var is not in
scope for Bar. There would afaik be several ways. So not a Dwarf
problem. <br>
<br>
------<br>
<br>
What is not foreseen in Dwarf is unit search order and visibility.<br>
If the Debugger encounter TGlobal, in which order should it search
other units.<br>
But, that knowledge would in a lot of cases not be worth anything,
and more so it may be contra productive.<br>
<br>
If a unit has<br>
var x: TGlobal;<br>
then debug info will point to the correct TGlobal. No problem.<br>
<br>
If you have<br>
Sender: TObject<br>
and a user enters the expression<br>
TGLobal(Sender)<br>
<br>
then that search order may not help. Sender could be of TGlobal,
even if TGlobal is NOT IN SCOPE for the current unit.<br>
So if the debugger would now stay in search order, you would just
get an error. <br>
Or the wrong TGlobal is in scope of the unit, and then you get the
wrong cast. <br>
Of course, the wrong cast can happen now too, with the absent
scoping.<br>
But the scoping would not add much help. <br>
<br>
-------------<br>
<br>
I don't know what the new format does in terms of calling params,
and stack resolution....<br>
But then again, currently we don't even fully use what is there with
DWARF.<br>
<br>
Would be interesting to know which shortcomings Graeme had
particularly in mind.<br>
<br>
</body>
</html>