FpDebug 1.0

[ynys_pas]

Just to be clear when installing lazarus on debian or ubuntu xcfe distro like linux lite, you have to install gnome debugger (gdb) before installing the deb files for it to work properly. is this still the case with lazarus 2.2 and its FPDebug?

[Martin_fr]

You can use Lazarus without gdb. (so no need to install it).

Just make sure the config was set correct after install. Go to Tools > Options > debugger. And check it is set to fpdebug.

Gdb is still supported as an option. If you later chose to use it, you can install it later.

[dbannon]

Martin, is fpdebug the 'recommended' debugger to use now ?  Is its use as good as gdb (or even better) ?

Which debugger is chosen by default in a new install of fixes_2_2 right now ?

I ask because I have the "Installing on Linux" wiki page saying you almost certainly need the GNU one. Is it time I changed that ?  Windows too ?

(Tools->Options->Debugger->DebuggerBackend, click "change type", choose "FpDebug internal Dwaf-debugger".....)

Davo

[Martin_fr]

FpDebug is the default and recommended. But there may be some cases where gdb still has the edge (debugging libraries for example).

On a new install (with no old config present) FpDebug should be selected automatically.
(The initial setup dialog however is still behind, and may look for gdb. That can be ignored.)

A general overview is here: https://wiki.lazarus.freepascal.org/Debugger_Status

The problem with recommendation of course is that people use the debugger in vastly different ways. And sometimes have grown fond of small details that I would not even be aware of. FpDebug was present (and use-able) since 2.0. But little feedback has come in since.

Based on my own debugging experience FpDebug beats gdb. A few points I am aware of:

- Debugging libraries. FpDebug does not support that yet.
- Stacktraces in system dll or kernel. GDB is better on unrolling the stack.
- cross bitness debugging => fpdebug in a 64bit IDE can debug 32 bit projects on Windows. But not the other way round. On Linux cross bitness has yet to be tested.
- remote debugging is still gdb only (except avr, thanks to ccrause)
- gdb has a better disassemble, if you need to go to asm level.
- support for external debug info was just added to fpdebug. Not sure if I did merge it to 2.2

However if you take your average project fpdebug should do all you need.
And it has better understanding of the data types and Pascal syntax. For complex types it will often show better values in watches.
With dwarf3 it also shows the names of locals correctly capitalized. (gdb does too, but gdb has a tenancy to crash with dwarf 3).
Fpdebug even has very initial (and very limited) support for function/method calling.

I have used FpDebug myself since before 2.0. Mainly on Windows. And it has worked very well for me.

[dbannon]

OK, thanks Martin. The people reading how to install on the wiki pages do not fit into the category of the power users with favourite gdb tricks.  But they would appreciate a slightly simpler install process so fpdebug it is !

I might also update the https://wiki.freepascal.org/FpDebug page too. Right now it does not know that fpdebug is now bundled in with Lazarus (>=2.2). Nice work, thanks !

Davo

[devEric69]

FpDebug was present (and use-able) since 2.0. But little feedback has come in since.

Here is mine little feedback. Personally, GDB slows down extremely - disappointingly, in fact, for me - when it comes to step-by-step debugging in the low-level libraries (Lazarus and fpc), while fpDebug remains consistently fast at all levels (project, packages, Lazarus or fpc) during a step-by-step debugging. I investigated to understand, but I didn't find why.

[Martin_fr]

Here is mine little feedback. Personally, GDB slows down extremely - disappointingly, in fact, for me - when it comes to step-by-step debugging in the low-level libraries (Lazarus and fpc), while fpDebug remains consistently fast at all levels (project, packages, Lazarus or fpc) during a step-by-step debugging. I investigated to understand, but I didn't find why.

Not that there is much that could be done (probably), but....

libraries as in dll or so? or units/packages compiled in?

There is some work in the IDE, but that should be consistent for all locations. Such as capturing registers (stack, base) before each step (required to continue the step for ignored exceptions etc).
Also getting stack,locals,watches. Those are discontinued if you continue to step. But whatever part was already sent to gdb has to be waited for.
Maybe it depends on gdb version too...

You can open the "history window" and switch it off (power button). If it is dll/so (and has on usable debug info), then you can in the global options set "disable load symbols for libraries" (in the property grid).

If it is assembler (or rather if the asm window is open) then that is a real slow down. You can use the power button on the asm. And only refresh (power on) when you leave the visible lines (and need to see new ones)

[devEric69]

Hello @Martin_fr,

This is over more than a year old now, and it's what made me definitely switch to fpDebug (unless I fall into one of the special cases listed above where GDB is more efficient, like remote debugging). The only thing I can remember clearly is that I've been trying to make sure that absolutely no debug windows are yet openend. Obviously. I only wanted to do 'F8' with GDB by being, remaining constant in speed, fast. I wanted just see the current highlighted line moved quickly.

Nevertheless, I remember perfectly that I could just see the borders of a small window starting to draw itself, starting to flicker. But nothing more. So, I've never managed to find out what this small window was. Sorry, today, I cannot say more (I know it doesn't really help). I always compile for debug purposes, with -O -g -gl -gw2 -godwarfsets .

[calebs]

thanks for the good work martin, i've using fpdebug since i heard of it and i am very satisfied with the speed that has in comparison with gdb. But i've had some troubles in the past debugging when i use tprocess calls  to execute another executables (in windows mainly) if i remember well that happen when i mixed 32 and 64 bit executables.
So i have to switch to gdb in that applications to debug those programs. I will test when 2.2 comes to see if those problems persist and if i can help to solve them.
Thanks!

[DonAlfredo]

Hello Martin,
I would like to inform you that debugging the mORMot[2] on Windows works much better with fpdebug, compared with gdb.
No crashed, good info.
So, many thanks !!

[Martin_fr]

Hello Martin,
I would like to inform you that debugging the mORMot[2] on Windows works much better with fpdebug, compared with gdb.
No crashed, good info.
So, many thanks !!

All ways good to hear some good news.