<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 20/11/2018 11:37, Dennis via lazarus
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:13fcb401-058b-6bca-02a6-db7c627a9efe@avidsoft.com.hk">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <font size="+1">FPC and Lazarus are great but the GDB is
        inadequate.<br>
        Many times in my development, GDB failed or crashed, especially
        when I am debugging multi thread programs.<br>
        <br>
        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).</font><br>
    </blockquote>
    <br>
    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.<br>
    Donations are still welcome.<br>
    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).<br>
    Best use Lazarus trunk (it is already ahead of fixes 2.0 branch, but
    by very little only)<br>
    <br>
    Support for threaded apps in fpdebug is not yet there.<br>
    Under Linux only the main thread is debugged. Windows has bare
    minimum  (and untested) support for dealing with threads.<br>
    <br>
    About using gdb.<br>
    - 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).<br>
    - Do not use dwarf3, this increases the risk of gdb crashes ("dwarf2
    with sets" is recommended)<br>
    - 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<br>
    - 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. <br>
    - Absolutely stay away from smart linking (for debugging). You can
    compile the units "smart linkable". But do not actually "smart link"
    the exe<br>
    - Not related to crashes, but stay with "NO optimization" -O-<br>
    - (fixes 2.0) On the debugger option (property grid): check and
    maybe reduce the various memory limits.<br>
    <br>
    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.<br>
    <br>
    Though yes, in the end, gdb may still crash. Depends on lots of
    stuff in your app.<br>
    <br>
    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.<br>
    <br>
    Also check <a class="moz-txt-link-freetext" href="http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips">http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips</a><br>
  </body>
</html>