Forum > Linux
Debugger
dryzone:
Earlier years Lazarus used gdb which was a very clunky debugger I never got any daylight out compared to the old turbo-pascal debugger which was exceptionally nice way back then.
Does anyone know if there is a debugger available similar to the TP debugger as I will only be doing console code and no gui work so dont need the entire Lazarus development Environment. If Lazarus did get a better debugger than gdb in recent years, please let me know as I cannot find definate answers doing searches about the topic.
I see there is FPDebug. How does it compare to the old Turbo debugger ? or is there a different debugger closer to the TP debugger.
I also watched this video
https://www.youtube.com/watch?v=gx0fP24-tqw
but it seems there is still a huge amount of problems and it seems to be still Beta.
Any advice will be appreciated.
Thanks
Martin_fr:
It meanwhile is out of the beta state.
However it is only intel/amd i386/x86. If you are on aarch, then it wont help you.
It is definitely better than the gdb variant.
As for any problems...
Well, there are properties like TStringList.Text => But that is in first an issue with the compiler. The compiler does not make it available for the debugger, then no debugger can not show it.
Console apps on Linux are bound to that inferior "Debug console" window (that is for all Lazarus debuggers / maybe except "remote debugger")
"OutputDebugString" (to log into the IDE debug event window) exists only on Windows. There is nothing on Linux. On Linux you only have writeln/debugln to console (or 3rd party solutions). That is the same for all debuggers (or some may not do it on Windows either)
For all else, I use it everyday. And that includes non-trivial cases. So it definitely works.
Remind me what other issues were in the video....
As for other debuggers.
There is an lldb wrapper. But that is Alpha (worse than the gdb, due to the wrapper), and is not actively developed. It is a byproduct of the "lldb+fpdebug" needed for Mac users.
You can use that "lldb+fpdebug" on Linux too, but it will not give you any known advantages.
There also is a "gdb + fpdebug" variant, but also no advantages. (and very little recent testing)
And there is a wrapper for gdbserver, but that wont help you either. Though with a lot of work you may be able to get debugging with your app running in a real terminal. But a lot of work, if at all.
And that is it. Well avr-remote, but not useful here.
You should give FpDebug a try.
If it turns out insufficient, then you can at least report it, and there is a chance that it gets improved.
Make sure you have Lazarus 3.8 (or at least 3.x).
And look out for Lazarus 4.0 which adds some more features. https://wiki.freepascal.org/Lazarus_4.0_release_notes#Debugger
If you need better asm/cpu view support, there is an addon: https://forum.lazarus.freepascal.org/index.php/topic,68962.0.html (probably needs Lazarus 4.0 at least, but don't know)
440bx:
--- Quote from: dryzone on March 07, 2025, 05:33:08 am ---Any advice will be appreciated.
--- End quote ---
The following applies to Windows only, because Windows is all I know, therefore I cannot emit an opinion about FpDebug on any other O/S.
On Windows, for debugging Pascal at the source level, FpDebug is really very good and, getting better all the time. I use it to debug both GUI and console apps without any problems.
If you're developing on Windows for Windows, you'll quickly see that FpDebug is an excellent debugger. The one part I feel still needs work is assembly level debugging but, that's being worked on too.
If you don't need assembly level debugging, it's quite likely you'll be very pleased with FpDebug.
Martin_fr:
--- Quote from: dryzone on March 07, 2025, 05:33:08 am ---I will only be doing console code
--- End quote ---
Unfortunately the support for console debugging is rather weak. That is because any debugger will have your output going into that build in debugger "console output" window, which really is no good at all.
In theory, but I never tested it, you can run a remote debugger. You should be able to start "gdbserver -... yourapp" in an actual terminal, and have the IDE connect to that (using the IDE's gdbserver backend as debugger). But you have to do lots of steps, and everytime your start debugging.
Afaik, both the gdb and FpDebug in the IDE offer a property "ConsoleTty".
If you go to: Tools > Options > Debugger > Backend (or define a debugger in the Project options).
Then for the selected debugger, there is a property grid with cryptic options.
In those options is "ConsoleTty"
Open a terminal and run "tty". It should output something like "/dev/pts/0" => that you put into the ConsoleTty.
Mind, if you close that terminal, you must remove the setting from ConsoleTty, and if you open a new terminal you must update ConsoleTty.
Then you need to block the terminal from taking any input, e.g. run "tail -f /dev/null" (it still takes ctrl-c - so you can't use that).
Now if you start your app in the debugger, the input and output of your app should go to that terminal.
Otherwise you can run any 3rd party debugger outside the IDE, as long as it support dwarf. (gdb, lldb)
But most of them will not know much about Pascal Syntax, so watching expressions will give poorer results.
MarkMLl:
--- Quote from: dryzone on March 07, 2025, 05:33:08 am ---I also watched this video
https://www.youtube.com/watch?v=gx0fP24-tqw
but it seems there is still a huge amount of problems and it seems to be still Beta.
--- End quote ---
Note that while that video is by the local expert, it's still a year old and this is an area of intense development.
In practice, at least under Linux, I find the Lazarus IDE more than adequate for developing and debugging console programs, or programs with mixed console and GUI functionality (e.g. depending on whether there were any commandline parameters).
The major caveat is that the IDE's "Console In/Output" window is poor at handling interactive programs, by which I mean something like a console-oriented text editor or something like the character mode FP development environment. I have to carry at least some of the blame for that: I added a few bits three or four years ago but could have done with doing far more. However, you can circumvent that weakness entirely by starting a program from a standard terminal and shell (Bash etc.), and then using the Lazarus IDE to attach a debugger to it: that works very well.
MarkMLl
Navigation
[0] Message Index
[#] Next page