Forum > Lazarus
FpDebug 1.0
devEric69:
--- Quote from: Martin_fr on September 12, 2021, 03:23:58 am ---FpDebug was present (and use-able) since 2.0. But little feedback has come in since.
--- End quote ---
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:
--- Quote from: devEric69 on September 12, 2021, 11:03:17 am ---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.
--- End quote ---
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 !!
Navigation
[0] Message Index
[#] Next page
[*] Previous page