Lazarus
Announcements => Lazarus => Topic started by: Martin_fr on June 23, 2021, 06:33:58 pm
-
FpDebug and LazDebuggerFp have reached version 1.0.
This means on Windows and Linux, the upcoming Lazarus 2.2 will use this as the new default debugger.
People who have configurations from prior installations already have config files containing the gdb based debugger. Those config files are not changed, and people are advised to change their debugger settings accordingly (once they upgraded)
GDB based debuggers are still fully supported, and for Windows a modified gdb of version 9.2 will be included in the installer.
None of those changes apply to Mac users.
EDIT
FpDebug works with Dwarf2 and Dwarf3.
Make sure to also compile packages with the correct debug info, if you need to debug them.
Dwarf3 should be preferred, but if you switch between FpDebug and Gdb, you may want to choose Dwarf2. Gdb does have some Dwarf3 related crashes.
Dwarf2 can be "Dwarf2 and Sets"
EDIT
FpDebug can not yet be used in the following cases. If you have projects to which that applies, you can change to the gdb debugger on a per project base.
In "Project options" is a debugger page, where you can select the gdb debugger.
- Debugging libraries
- Using external *.dbg debug info files
-
Martin, congratulations on getting the debuggers to this point of development and usability.
I know many Lazarus users would join me in thanking you, Marc (and others too, but you particularly) for all the months of work this milestone represents.
-
thanking you, Marc (and others too, but you particularly)
Not to forget, Joost has also done some good parts. Thanks to him, there is some first ability to call functions in the debugger. (Object methods from bases in other units to not work / so sorry, but no TList.GetCount)
Also, this part is still alpha. Use at your peril.
-
https://wiki.lazarus.freepascal.org/Debugger_Status
-
Thanks, Martin!
-
Thanks!!!.
One question. This debug supports remote debuging?
/Blueicaro
-
Thanks!!!.
One question. This debug supports remote debuging?
No. For that gdb is still part of the installer.
If you need that on a per project base, then you can set a debugger per project.
Also
=> FpDebug is only for Intel/AMD. (And only Linux/Win)
=> If you run on ARM, then you need gdb.
There is no work on extending that yet (also it is on the "would be nice" list)
(
Well there is some contributed work going on for an avr version of it https://github.com/ccrause/lazarus
I have to check the state of it in Lazarus trunk
)
-
Can new debugger evaluate properties with getters/setters ? This is very long awaited feature )
-
Can new debugger evaluate properties with getters/setters ? This is very long awaited feature )
Not, yet.
But, first progress in this direction has actually been made. Joost added "function calling in watches" (so a lot of functions currently are not avail for calling).
Afaik, Joost is now also looking into adding the requirements to the compiler.
The problem with properties has always been many fold.
The debugger can only access data, that the compiler provides in the debug info.
At current properties are not included in this. The compiler doesn't put the info in there.
To make it worse, the debug info format, does not even provide an official format for that.
But it allows to add proprietary data.
(Afaik) Joost is now working on adding such proprietary data.
So when he is done, that goes into the (then to be) next major fpc release.
Since FpDebug has function calling (though that needs to tested, and likely improved / but it is there), once Fpc writes the data, it will work.
Calling function in watches.
*** This is new and not much tested / If it crashes, report it. But do not complain about your IDE taking the current session to the grave ***
Must be enabled, in global debugger settings.
Must be enabled per watch.
Works only for
- plain functions (not methods)
- methods, if and only if, their function body (the actual code) is in the same unit, as the declaration of the variable holding the instance you are inspecting
var a: TMyList // in unit42
watch: a.GetBar(); // "function TMyList.GetBar()" must be declared and implemented in unit42
// if "a" is global, then your "current execution line" can be anywhere else
- must be called using ()
- must return an ordinal type (no strings yet)
- takes either no arguments, or only 2 or 3 arguments max (depends on OS)
- all arguments must be ordinal types
As I said, this is all very new. It's not yet indented for real use. But it is progress. There is actual work on the issue now.
-
Can new debugger evaluate properties with getters/setters ? This is very long awaited feature )
Just a side question out of curiosity: Does Delphi support that?
-
Just a side question out of curiosity: Does Delphi support that?
AFAIK: Yes. And this is what Joost, Martin, ..., are working on ( getters/setters are functions and procedures to be evaluated in the debugger ).
-
Delphi also has visualizers that improve the view of certain common classes like tlist/tstringlist:
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Debugger_Visualizers
-
Delphi also has visualizers that improve the view of certain common classes like tlist/tstringlist:
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Debugger_Visualizers
The entire debugger frontend could do with a big redo/improvements...
-
Can I use it in my editor to debug simple pascal (one based program file .pas) or to debug some gnu compilers like c/c++?
-
There is no stand-alone fpdebug (yet / nor will be in a while / nor will it necessarily have gdb compatible in/output).
So probably no.
Unless "your editor" is the editor you wrote, and you want to include the fpdebug package, as well as you have some front end to interact with it. (note that iirc fpdebug is gpl, not lgpl)
"c based" should be ok-ish.
That is it should be reading the dwarf info and be able to access the data just fine.
But it will display them pascal-ish. And expect watch input to be pascal.
E.g. Foo^.bar rather than foo->bar
Both input and output are separated from the rest, and can be replaced with modules for other languages.... But currently there is only pascal. (And the interface they use may still change...)
-
Yes I meant my open source editor I wrote it, and there is another editors used Lazarus,
but mine I am working on it, have PHP debugger, with abstract class for Step by Step in source code, and watch hint etc, and I want to add gdb debugger support.
https://github.com/parmaja/miniedit
and thank you for your efforts :)
-
Well if you integrate the DebuggerInf then you can use any of the debuggers in the IDE.
If you do, and you have comments on the DebuggerInf and how to improve it => welcome.
---
package LazDebuggerFp does this in the IDE.
Also give you an idea how to do stepping.
(Note that there is very strict which thread may access what data)
Some parts (like handling seh exception) should move to FpDebug eventually.
--------------
FpDebug is also used by Joost's debug server https://gitlab.freepascal.org/Joost/fpdserver
that implement DAB
-
Small question: i noticed that with 2.2 RC1 "OutputDebugString" does no longer generates output for the event window ("Ereignis-Protokoll"). // OS Windows
I use it oftenly as a little helper for to trace something temporarely, without needing then additional includes (except unit Windows) or logging frameworks.
Is that by intention or can i reactivate a usage of OutputDebugString by a setting?
Debugger info type is still set as before (Dwarf2).
-
Small question: i noticed that with 2.2 RC1 "OutputDebugString" does no longer generates output for the event window ("Ereignis-Protokoll"). // OS Windows
I use it oftenly as a little helper for to trace something temporarely, without needing then additional includes (except unit Windows) or logging frameworks.
Is that by intention or can i reactivate a usage of OutputDebugString by a setting?
Debugger info type is still set as before (Dwarf2).
If you use FpDebug, that is probably not implemented.
You can switch to gdb. (global or per project)
If you did use gdb, then that may be because it's a different gdb version.
You can install other gdb...
-------------
I never used the command.
Btw there is a package lazDebugServer. No idea if related.
-
Hm, i'm compiling for the Windows platform, but never did choose intentionally which kind of debugger i use - i was happy with the default.
When recompiling the project with 2.2 RC1, as of the Release Notes the debugger default did change:
LazDebugger-FP (FpDebug) v1.0 is now the default for new installations on Windows and Linux.
So i did assume the change was due to this switch of the defaul to FpDebug.
Seen for itself i've no specific reason to switch to another debugger.
-
Does Fpdebug show variant value? I means in case I have a Variant variabile can I check its values ?
-
Does Fpdebug show variant value? I means in case I have a Variant variabile can I check its values ?
Ah, good question. Something I had not even thought of at all...
Tested => no.
But from an quick glance, the data may be in the debug info. Then it should be possible.
Please file a feature request on mantis, so it wont be forgotten.
----------------
That is why testers are needed.
I can't possible think of every use case myself....
-
Actually, dwarf 2 shows it as a record.
Only dwarf 3 does not.
-
Just added
https://bugs.freepascal.org/view.php?id=39233
-
How do I use it?
I only have gdb, gdb through ssh, gdbserver and LLDB in the dropdown list.
Lazarus 2.2.0RC2 rfixes_2_2-0-gc60b5f9a7e FPC 3.2.3 x86_64-linux-qt5
-
There should be an "LLDB debugger (with fpdebug) (Beta)" option.
If not, from the main IDE screen, click Packages->Install/UninstallPackages. Shown is two lists of packages, the list on the left is installed, the list on the right is available to install. Look for LazDebuggerFpLldb (exactly that, there are some similar named but less suitable packages). If it is on the right hand side, click it, press "Install Selection" and then "Save and rebuild IDE". This will take a little time, the IDE will shutdown and restart and all should be well.
-
Ok, I installed the missing LazDebuggerFpLldb and now I can select "LLDB debugger (with fpdebug) (Beta)".
But is is still missing something:
When seting a breakpoint it complains
"Es ist kein Debugger angegeben.
Das Setzen von Haltepunkten ist wirkungslos solange nicht im Debugger-Einstellungsdialog im Menü ein Debugger festgelegt ist."
(Translated: There is no debugger selected. Can't set breakpoints if there is no debugger selecte in the debugger settings dialog")
Then I enter this dialog again and the only binary I can select is gdb. If I select gdb it will complain during debugging that it expected someting else.
-
I built my Lazarus with fpcupdeluxe, is it possible that fpcupdeluxe "forgot" to build the debugger binary?
Should this have happened automatically or should I file an issue with the fpcupdeluxe project once LongDirtyAnimAlf is back from his 2 weeks mountain climbing vacation?
-
Lazarus 2.2 RC1 contains Martin's new "FPdebug internal Dwarf-debugger" which requires no additional binaries.
Older Lazarus versions allow the installation of LazDebuggerFpLldb which needs the lldb debugger binary to be installed (as it is, eg, natively on macOS). You will need to install lldb if you wish to use it instead of gdb or install Lazarus 2.2. RC1.
-
How do I use it?
I only have gdb, gdb through ssh, gdbserver and LLDB in the dropdown list.
Lazarus 2.2.0RC2 rfixes_2_2-0-gc60b5f9a7e FPC 3.2.3 x86_64-linux-qt5
If you build from sources, with your existing config, you may have to install the package yourself. Package: LazDebuggerFp
-
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?
-
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.
-
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
-
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.
-
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
-
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.
-
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)
-
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 .
-
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!
-
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 !!
-
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. ;)