The below mention commit removes writing of class constants.

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

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

It breaks GDB. But not because GDB doesn't deal with "incorrect dwarf" It breaks GDB because GDB's Pascal mode is severely broken, and declining. GDB has comments "we haven't seen that by any producer, so we don't support it yet" (that may include: just not seen, because not tried hard enough).

And yes its the Pascal part of GDB:
When compiled with -godwarfcpp then this incorrect dwarf works => so maybe that could have been kept?
Yes, its still wrong Dwarf, so ok, still correct to remove.

But then, why not: REPLACE?
Wouldn't that be better?
There is correct and valid DWARF to implement this. In DWARF-5 => but I made an MR for DWARF-5, and then can easily make one for the "class const" as follow up.

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.

Given that we have a switch -godwarfcpp => should we not then also have one for -godwarffpdebug ?

If we go by the minimum between gdb and lldb => given that gdb is shrinking its minimum (the string tag worked in gdb 12 but no longer in gdb 17 at least not for pascal) there wont be much left.

---------------------------------------

Out of sheer curiosity:

Why is there a (reverted) commit that attempts to fix this by removing the constant from TObject (and leaving the dwarf info as is)?

---------------------------------------
Revision: f6173555587ac61276919f37fac6b308dad53acd Author: Pierre Muller
Date: 28/04/2026 23:08:18
Message:
Disable writing dwarf debug information for constants inside object or class (as it leads to crashes in GDB)

program ClassVar;
{$Mode objfpc}{$H+}
{$ModeSwitch advancedrecords}
type
   TTest = record
   ab: word;
   public const
   d = 5;
   end;
var a,b:TTest;
begin
a.ab:=1;
end.

Martin Frb wrote

It breaks GDB because GDB's Pascal mode is severely broken, and declining.

And just to show that:

Compiling for 32 bit, and using an **older** gdb on Windows:

GNU gdb 6.7.50.20071127
Current language:  auto; currently pascal
(gdb) p a
$1 = {ab = 0, static d = 3}

It was able to print that for records. (well it gets the value wrong) (I did not find the version that worked for classes too, though older v.6 did not crash, but just say "optimized out" for the constant)

And again, making gdb believe its a "c" app, and a lot more suddenly works.

Le 29/04/2026 à 22:45, Martin Frb via fpc-devel a écrit :

The below mention commit removes writing of class constants.

I did commit this indeed.

GDB is generating an assertion error when trying to dispaly the value of these constants.

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, before my commit, I wasn't able to debug the Free Pascal trunk compiler using GDB.

I still have not enough knowledge about Dwarf internal to understand all those issues. For that reason, I would prefer that Jonas or Florian would look at you MR concerning DWarf improvement and FpDebug specifics.

And yes its the Pascal part of GDB: When compiled with -godwarfcpp then this incorrect dwarf works => so maybe that could have been kept? Yes, its still wrong Dwarf, so ok, still correct to remove.

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?

Adding support for Dwarf-5 is certainly a good move, but again, I do not feel competent in that area, sorry.

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

Pierre

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.

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.

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

Ah, ok...

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

set language c++

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

Pierre Muller wrote

I am still the official Pascal maintainer of GDB, but I didn't do anything to improve GDB for a looonng time.

From the point of FPC => is there an established way of testing the generated dwarf?
I mean other than: its being used...

Is there an automated way?
E.g. checking with selected versions of gdb/lldb that certain data can be processed?

Problem I see here is "selected version", as regressions in gdb don't mean that the fpc code is broken...

Le 30/04/2026 à 00:21, Martin Frb via fpc-devel a écrit :

I tried recently to use dwarfdump, a standard unix utility, and this tool does indeed list a few issues with
the DWARF information generated by Free Pascal.

I didn't have time to investigate these issues.

Pierre

I usually use objdump --dwarf=....

But I am not sure either is a good test...

Well it is, if you do something like I assume gcc does with its dwarf-strict option.
But that doesn't guarantee much. Since their is plenty of correct dwarf that gdb does not handle.

So I guess then there is no automated test, that "feeds" gdb, and checks the results?

Pierre Muller wrote

  I tried recently to use dwarfdump, a standard unix utility, and this tool does indeed list a few issues with the DWARF information generated by Free Pascal.

Ok, I tried dwarfdump myself.

Just a random glance into the output, some may be easy to fix (there is a missing OP_nop for a OP_skip to end)...

I haven't gone through many yet.
But, just blindly fixing them may not even help (not even for gdb).

Its very possible that some stuff happens to work with gdb, because its "special". And that getting it right breaks gdb (as we know for fact that gdb does fail on various valid encodings).

I was thinking about a tool (maybe to be included in automated testing) that could run gdb and lldb on given test-code (including compiling that code).
And then inject commands like "p MyObject^" and regex the output for known field-names and -value (the formatting of those doesn't matter, only the presence).

If that is of interest I may further look into it.

But,
=> while I am all for improving the gdb compatibility, => I don't have any motivation to kill off features used by FpDebug

If the latter can be replaced (with something that works for gdb too) => good.

If not, then I really would want to have some feedback on other options. E.g. introducing "-godwarffpdebug"

Even if that would include some "not so strict" implementations. Even gcc has "|-gno-strict-dwarf" to allow some digressions... (ok, so long as the receiving debugger will be fine...).|

GDB already has that built-in. I've used it extensively in my projects for automated tests.

There are two primary ways to do this: using the `-ex` flag for quick commands or the `-x` flag for script files.

Example: Run a program, print a variable, and exit

$> gdb -batch -ex "break main" -ex "run" -ex "print my_variable" -ex "bt" ./ my_program

* `-batch`: Exit after commands are done.
* `-ex "break main"`: Set a breakpoint at main.
* `-ex "run"`: Start execution.
* `-ex "print my_variable"`: Inspect the value.
* `-ex "bt"`: Print a backtrace.

Using `-x` (Command Files)
--------------------------
If you have a long list of breakpoints, watchpoints, and print statements, putting them in a text file is much cleaner.

Step 1: Create a command file (e.g., `debug_script.gdb`) ----[gdb]----
set pagination off
break main
break process_data
run
# Wait until we hit the second breakpoint
continue
print current_status
info locals
bt
quit
-----

NOTE: `set pagination off` is critical for batch mode so that GDB doesn't stop and ask you to "Press enter to continue" when printing long outputs.

Step 2: Run GDB with the script

$> gdb -batch -x debug_script.gdb ./my_program

Regards,
Graeme

Not exactly what I meant... If you do it this way, then you can only match the entire output against one expectation for it all.

As a human, that is fine, => if you want to run it manually and see.. Though, if you want to test hundreds of values, then you would not check them all manually.

I actually had already started something.

It takes a list

p data | val\b.*\b42

gdb command, pipe, regex
=> and that regex must match the output of exactly that one command.

And then it can loop over lots of them.

The tool also takes the location of the compiler, and the location of the pas source.
But, if you want to test against several versions of gdb, then you need to run several times.

The question to the fpc team then is, would they want to add that to the test suite?
That would mean there needs to be  (at least) one gdb in a known location. And then the freshly build fpc, would be asked to compile the test-sources, and they would run through gdb (or lldb).

Of course you change the version of the gdb used, and then you may need to do updates to the test.

BST Martin Frb wrote

Not exactly what I meant... If you do it this way, then you can only match the entire output against one expectation for it all.

Maybe not 100% what you described, but it sound like it's very similar in concept to my integration tests (not unit tests) I defined for OPDF's cli debugger.

https://github.com/graemeg/opdebugger/tree/master/tests/integration

Maybe there is something useful you could reuse.

* Integration tests are trigger by running the 'run_test.sh' script.
* Each test has *.commands as input and *.expected as what it expects.
* The test run creates a *.diff file. If that file is not 0 bytes, something broke.

Regards,
Graeme

Yes of sorts.

Only an exact diff is not necessary the best test. We aren't in charge of gdb, and if we want to cover a range of versions, then we can't always predict the exact formatting. Nor do we need to.

If I want to test a TPoint(10,20) works, then I just need to check that it printed x and y with those values (and maybe that its a record not a class).
It does not matter if GDB uses round, square or curly brackets. If it uses , or semicolon....

With opdf you control all that formatting. You even may want to ensure its formatted correct.

I just did try myself.

The list definitely includes false positives.
dwarfdump [Mar  6 2026 19:38:46 (libdwarf 2.3.1 dwarfdump 2.3.1)] And the latest 3.3.1 fpc

Proof?
*** DWARF CHECK: DW_TAG_compile_unit -> DW_TAG_interface_type: tag-tree relation is not standard. ***

1) The dwarf docs don't say anything that wouldn't allow this. And as other types are declared in the CU, where else should an intf be?

2) From dwarfdump sources
https://github.com/avast/libdwarf/blob/master/libdwarf/dwarfdump/tag_tree.list

2a)

2b)
DW_TAG_interface_type is not listed as possible child to any of the other tags.

It is only listed as a parent specifying which children it can have. So given the list in the above file, it couldn't be used anywhere at all.