GDB 17 for Windows

[Martin_fr]

For anyone still using GDB on Windows (e.g. cross debugging 64bit target apps from a 32 bit IDE), I have uploaded builds of GDB 17.1

64 bit: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
32 bit: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/

There are still issues with FPC generated targets under this new GDB version. I haven't made any comparison to the old versions. So don't throw away your existing one.

[nanobit]

Can this new GDB also be used in installations before Lazarus 2.2 ?

[Martin_fr]

In theory yes. In terms of the communication protocol between IDE and GDB, the changes are not that big.
I did a quick test with Lazarus 1.8.5 => It start a simple GUI app and reaches a breakpoint.

You have to compare how it works for your case. It may only differ in small details.

To be on the save side, used "Dwarf with set".

You can try to use "Dwarf-3", but that may still be less stable than "Dwarf with sets".

[Martin_fr]

Just a note.

The issues when debugging with GDB come from a variety of places.

1) GDB itself has issues. Even 17.1
Actually I found some new ones in 17.1 but those (that I found) are not triggered by any FPC version. I found them with a modified FPC version.

2) FPC
FPC (used to) write some buggy debug info. No matter what GDB you use, that can lead to issues.
Those are still present in 3.2.2 (not sure about 3.2.3). And presumingly you are using a way older version?


The question is what you are looking for?

- Getting rid of GDB "crashing" during debugging? (then maybe the newer GDB will help)

- Getting more details on inspected data
That wont have any changes. (or very very little / I can't test everything)
You can try to change between debug formats, but even that will not make much of a difference.


In theory (not tested / a bit of work / and a lot of attention not to screw up)...

You can compile with Lazarus 2.2 => and then debug with Lazarus 4.8 using FpDebug. But if you don't pay attention, you screw up your config, potentially even your project.

You would need to have both installed. Then after compile open the project in the new IDE and debug.
For that it must be set to "not compile" (in project settings).

But if the new IDE writes the project file, the old wont read it. So you better maintain 2 project files. The new IDE just needs a dummy project to point to the exe and the sources (and being set to "not compile")

[nanobit]

Thanks, I've exchanged the gdb binary under an old installation (Lazarus2.1), have changed nothing else and it seems to be more stable than previous versions. But I've noticed also something new: Under gdb 17.1 certain invalid assembly (compiler bugs) can lead to an empty assembly view (and the debugger freezes therefore), whereas with older gdb the assembly listing was longer (allowed deeper stepping).

[Martin_fr]

If you want ,you can check the "Debug output" (not "console") window in "view" >  "debug windows" (newer Lazarus in "IDE Internals"). And see if gdb hangs..

Though the knowledge want make to much difference... I do seem to recall that the IDE had some issues putting the asm together (as it is received in blocks, and they need to "join up").
Its possible that a slight diff result from gdb (never mind if correct or not) can trigger something like that in the IDE.

But if the IDE goes into an endless loop, then there is little to be done. Since that old an IDE does not receive fixes anymore.



If you are on 64 bits.  I have an older build, that's been laying around forever. I only have it for 64 bit.
Its gdb 12.0.50  (not sure if it was from a tag, or if I did build from the branch....).

IIRC, I used that a few times, and it wasn't to bad either. So if you want to give it a go...
(I put it on the snapshot site for now)

https://sourceforge.net/projects/lazarus-snapshots/upload/Window%2064/gdb/