[fpc-devel] RECENT Commit breaking FpDebug - Dwarf / and not even fully fixing the original issue

[Martin Frb]

On 29/04/2026 23:45, Pierre Muller via fpc-devel wrote:
>> It also breaks this for FpDebug, which was able to show them. (btw, gdb
>> can too)
>> Though, it is still correct.... (more or less).
>> I agree, we do need DWARF that works with GDB...
>>
>
>  GDB is generating an assertion error when trying to dispaly the value 
> of these constants.
Yes, if language is Pascal.
 From what I could find (and I am not very acquainted with the gdb 
source, so its little), if GDB does not see an address, it checks that 
the bitoffset is 0. => but it that check asserts that a bit address must 
be explicitly given.

>
>> Which leads to an interesting question
>> - Why wasn't it fixed?
>> It now works for classes, but is left broken for advanced records (see
>> example at the end)....
>
>   I do not understand what you mean by saying that it is now fixed,
Well, GDB no longer asserts/crashes (when you build gdb without assert) 
when it prints a class.
=> so printing a pascal class in gdb is now fixed.

> before my commit, I wasn't able to debug the Free Pascal trunk 
> compiler using GDB.
Yes, exactly. And that is fixed.
Well, except for records with constants.

>>
>>
>> Only problem: gdb is broken if the language is set to Pascal.
>> The valid DWARF-5 works if the language is c++. But of course not, if it
>> is Pascal.
>
> I am still the official Pascal maintainer of GDB, but I didn't do 
> anything
> to improve GDB for a looonng time.
>
> I would maybe make more sense if you would directly step up to volunteer
> as Pascal maintainer of GDB?

As just mentioned, my GDB source knowledge is almost none existent.
Also never done much with any c/c++ variant. I can read it...


>> Why is there a (reverted) commit that attempts to fix this by removing
>> the constant from TObject (and leaving the dwarf info as is)?
>
>   This is how I did on several test machines to be able to use GDB to 
> debug Free Pascal compiler.
> I pushed this local change by accident, that is why I reverted it.
Ah, ok...

I really was surprised, it didn't make sense as a real fix.

> We had a discussion on core when I raised the issue about the fact 
> that adding a constant
> field to the system TObject (which is the base class of all classes)
> completely broke the usage of GDB, as any inspection of a class instance
> led to a internal assertion error inside GDB.

set language c++

doesn't fix all, but a few things get better.
But it means
   p *MyObject
instead of
   p MyObject^