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]

Any advice will be appreciated.

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]

I will only be doing console code

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]

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.

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

[dryzone]

Thanks all for the excellent advice.
I have a lot to work through based on all the advice, but I have the general direction and I thank you all very much.
It will be a while before I worked through all that and report back.

Last question. Does fpdebug have a stand-alone application ?  that would be nice as I currently have a lot of trouble to get Lazarus installed, and I dont need any gui development for this project, so Lazarus IDE is largely unnecessary except for running the debugger. Standalone would be great.

[440bx]

Does fpdebug have a stand-alone application ?

Not at this time.

I don't think there is even one planned, hopefully Martin will confirm that one way or the other.

[Martin_fr]

There are no plans for a standalone GUI driven FpDebug. (But it could be done by 3rd party).

There is a (broken): fpd
Sources in the lazarus component/fpdebug dir. Which is (or was) a command line debugger using the FpDebug backend.
But it has not been maintained in years (a decade?), at best it may compile. I would not expect it to run, and if it did, it would be missing almost all features.
On the very long run, that may be restored to live... But not anytime soon.


If you need Lazarus for the debugger only, then just use FpcUpDeluxe to install the latest fixes-4 branch.

That way you get many of the latest fixes for the debugger. And afaik that runs well on almost any distro. (And if not, the author is on the forum and usually responds).

Of course if your issues aren't "installing Lazarus" but rather "running Lazarus" that may not help. From what I hear, there are some versions of Wayland that are either themself unreliable, or at least make Lazarus run less stable. So if your system has such a Wayland version, then there may be trouble. (Afaik FpcUpDeluxe allows you to select QT, and maybe that will help / no idea / not tested myself)

[JuhaManninen]

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.

Often console programs take input parameters and then read / write files etc.
The debugger works perfectly well for that. You can set breakpoints, step line by line and see variable values in Watches window. What else would you need?
Yes, FpDebug is in a good shape.