On 25/04/2026 19:55, Martin Frb via fpc-devel wrote:
Though, I did not test stabs.
There is some old, incorrect DWARF code that generates wrong info for
type TFoo = class
public const X = 1;
end;
And, that causes an assert failure in gdb (at least mine).
...
Try above, with DWARF.
To inspect the variable
var MyFoo: TFoo; //MyFoo:= TFoo.create;
in GDB
p MyFoo^
without deref, gdb only prints the address.
I did re-run some of my gdb tests v12 and v17 on Win64
When forcing "set language = c++" then gdb accepts the dwarf info.
Any of
- the current wrong one
- DWRAF-5 TAG_Variable (even when dwarf version is set to lower than 5)
When the language is pascal, gdb will fail that in any case. It will try
to check for a bit offset, but as their is no bitoffset attribute, that
triggers an assert.
That is an issue in gdb.
I found comments in gdb that state "there may be other value, but we
haven't seen them used, so they aren't implemented" => and gdb
introduces more and more language dependent code.
------------------------
In any case, that means (probably / not explicitly tested) when using
-godwarfcpp the current info is workable for gdb.
Question is, what to do when -godwarfcpp isn't given?
Assume that the debugger will be FpDebug (that is only true for a few
platforms)
Add a -godwarfFpDebug ?
Just apply the Dwarf-5 MR
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1447
, and fix it for Dwarf-5 => making Dwarf-5 the go to for fpdebug? (and
any other debugger if it implements this)
(adding TAG_Variable for that case would be easy)
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
