[Lazarus] what can we do to get a better debugger

[Martin Frb]

On 20/11/2018 11:37, Dennis via lazarus wrote:
> FPC and Lazarus are great but the GDB is inadequate.
> Many times in my development, GDB failed or crashed, especially when I 
> am debugging multi thread programs.
>
> Shall we start a fund raising event to raise fund for a new and better 
> debugger for FPC + Lazarus? (provided there are talents out there who 
> would do implement it).

That work is already in process (though very slowly / work has 
started/stopped plenty of times over the past many years). It is called 
FpDebug.
Donations are still welcome.
Under Windows and Linux you can install the package LazDebuggerFp. (You 
can do on Mac too, but then you need to codesign the entire IDE).
Best use Lazarus trunk (it is already ahead of fixes 2.0 branch, but by 
very little only)

Support for threaded apps in fpdebug is not yet there.
Under Linux only the main thread is debugged. Windows has bare minimum  
(and untested) support for dealing with threads.

About using gdb.
- If on windows, test the alternative gdb downloads from our sourceforge 
site. (Newer is not always better / but there is no generally best 
version, depends on many factors).
- Do not use dwarf3, this increases the risk of gdb crashes ("dwarf2 
with sets" is recommended)
- On win64, there are issues with single stepping. Potential workaround: 
compile the project (and all packages that have debug info) with -Xe -al 
(external linker and assemble) => that is slow, but may help
- Always ensure that all packages have the same type of debug info. If 
you compile the project with "dwarf with sets", then any package (unless 
it has no debug info) should also use "dwarf with sets" ("dwarf2"  (aka 
"dwarf"/-gw in the IDE) and "dwarf with sets" are compatible too). You 
can use "additions and overrides" to ensure this.
- Absolutely stay away from smart linking (for debugging). You can 
compile the units "smart linkable". But do not actually "smart link" the exe
- Not related to crashes, but stay with "NO optimization" -O-
- (fixes 2.0) On the debugger option (property grid): check and maybe 
reduce the various memory limits.

If crashes happen while examining values try installing the package 
LazDebuggerFpGdbmi, and set the debugger type to "gdb (with fpdebug)". 
All the above still applies.

Though yes, in the end, gdb may still crash. Depends on lots of stuff in 
your app.

For Mac, we have an LLDB based debugger now. It works on other platform 
too (if lldb is available and stable). But it is less feature rich.

Also check http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181120/5301a07e/attachment.html>