lldb on windows? lazarus / 12-Debugger ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-02 19:21 Lazarus suppots lldb on Windows? Because i saw binaries for codetyphon.. ---------------------------------------------------------------------- Martin_fr · 2019-01-02 19:43 Yes it does. (Lazarus 2.0RC and up) You do need to download a working copy of lldb yourself (from the llvm project, or any source of your trust). The lldb you use, must support the correct bitness (32/64). However may I ask which problem you try to solve? What do you try to gain? The lldb based debugger has less features, than the gdb based one. And probably is no more stable... (I doubt that differs for codetyphon, how long ago did they add it? We developed our lldb supporting code last autumn) Though of course it may be possible that a very particular bug, is not present in lldb, while it exists in all versions of gdb... / In most cases there is a version of gdb that will do better. Depending on what you want to achieve, there are more options: - gdb with fpdebug - fpDebug ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-02 20:00 Can you explain how to set it up on windows? Would appreciate. ---------------------------------------------------------------------- Martin_fr · 2019-01-02 20:18 Same as explained here for Mac. You need at least a current 2.0 RC of Lazarus (or svn trunk or fixes2.0 branch). In older RC versions you need to install the package (Package menu) LazDebuggerFpLldb You need lldb.exe (probably install a full llvm) Do NOT use the snapshots, they do not always contain lldb. This *should* work (IIRC) http://releases.llvm.org/download.html#7.0.1 Actually I tested with 6.0.1 sofar. But I guess 7.0.1 should be fine too. In Tools > Options > Debugger   In the "debugger type" dropdown, you should find and select "LLDB debugger (with fpdebug)"   The edit below this (where you normally have the path to gdb), should be changed to the path of lldb (where ever you saved yours) If you run into issues please describe which step, and what issue. --- Edit - gdb with fpdebug - fpDebug - lldb WITHOUT fpdebug (NOT advised) are all available by installing the correct packages: LazDebugger.... On Windows FpDebug is really worth a try.... Edit2 Note that our source page also offers "Alternative GDB" in the Windows32 / Windows 64 sections. So if the default version of gdb does not work well for you, you can try newer versions. ---------------------------------------------------------------------- Martin_fr · 2019-01-02 20:39 Quote from: r2r3 on January 02, 2019, 08:21:25 pmLazarus suppots lldb on Windows? Because i saw binaries for codetyphon.. According to their screenshots, it seems code typhon uses the "without fpdebug" version of lldb-based debugger. This version is pure lldb. Meaning all watches input and output require c style syntax. Background: LLDB does not understand Pascal. So afaik it expects "Objcet->field". And it prints stuff in c-style too. Lazarus has a debugger that combines lldb with the abilities of fpdebug. So you get all the pascal syntax. ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-02 20:40 Excellent. Will test! ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-02 21:37 Seems to work! Also its much faster than GDB. However there is some problem with this demo. It will just debug ASM after first dll call. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; {$mode delphi} uses Windows; type  int = longint;  bool = boolean;   function printf(const format: pchar): int; cdecl; varargs; external 'msvcrt.dll';  procedure getch(); external 'msvcrt.dll' name '_getch'; begin  printf('two numbers %d', 3);  printf('two numbers %d', 3);end. ---------------------------------------------------------------------- Martin_fr · 2019-01-02 22:03 Quote from: r2r3 on January 02, 2019, 10:37:07 pmSeems to work! Also its much faster than GDB. Which lldb are you using? with/without fpdebug? If you want speed, use pure FpDebug (package LazDebuggerFp). (no cross debug though) You can also use "gdb with fpdebug" LazDebuggerFpGdbmi. It's fast on windows, if you compile with Code: [Select]-dWithWinMemReader QuoteHowever there is some problem with this demo. It will just debug ASM after first dll call. You mean inside the dll, or when stepping over the 2nd "printf" in your own unit? Stepping depends purely on what lldb supports. Btw: make sure you use "dwarf" (default for 64 bits, but not 32bits) ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-02 22:34 Yes instead of going over the function it just starts debuging ASM on both x64 and x86.. I use fpdebug LLDB.. Seems to happen only with dll's ! ---------------------------------------------------------------------- Martin_fr · 2019-01-02 22:47 Quote from: r2r3 on January 02, 2019, 11:34:10 pmYes instead of going over the function it just starts debuging ASM on both x64 and x86.. I use fpdebug LLDB.. Seems to happen only with dll's ! Can you try getting a log? (edit the windows shortcut to lazarus) Code: [Select]lazarus.exe --debug-log=C:\path\to\yourfiles\laz.log --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DE BUG,FPDBG_DWARF_ERRORS,FPDBG_DWARF_WARNINGS,FPDBG_DWARF_VERBOSE_LOAD,F PDBG_DWARF_DATA_WARNINGS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS ,DBG_THREAD_AND_FRAME There is a (un)known issue with current fpc (3.0.4, afaik 3.2 fixes and afaik trunk) where both gdb and lldb appear to sometimes do weird stepping. IIRC this was not present in earlier fpc (not sure about 3.0.2). https://bugs.freepascal.org/view.php?id=34159 ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-02 22:54 Is it possible to speed up GDB on Windows? --disable-nls seems to help a bit. ---------------------------------------------------------------------- Martin_fr · 2019-01-02 23:37 Depends on which part you want to speed up? Start up? - A tiny bit by "DisableLoadSymbolsForLibraries" - Make sure "reset debugger after each run" is NOT checked Evaluation of watches? - Set all Memory limits to the same value - Ensure any package you do not debug, is compiled without debug info => Use gdb with fpdebug, and compile the IDE with  -dWithWinMemReader Stepping? - Not really (Note you can continue stepping before watches are done). You can use the power off button in most debug windows, to prevent them from updating. If you also "power off" the debug history window, then the IDE will not ask gdb for any data it does not need. This may in some case improve stepping. If you continue stepping, the IDE will stop asking gdb for locals/watches etc. But it still has to wait for the one that is already requested from gdb. If you power off the windows, and the IDE does not request anything, then there is not even the wait for the current requested.... But in most cases this will be hardly noticeable. ---------------------------------------------------------------------- Martin_fr · 2019-01-02 23:39 Did you try pure FpDebug? This is the fastest you can get! ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-03 09:21 fpDebug seems to crash for me. LLDB seems to work fine it just doesn't skip over dll calls.. and goes directly in to ASM. ---------------------------------------------------------------------- Igor · 2019-01-03 12:26 Quote from: r2r3 on January 02, 2019, 10:37:07 pmSeems to work! Also its much faster than GDB. I noticed that GDB in 64-bit Lazarus works much FASTER than GDB in 32-bit Lazarus. My app is also works faster and more responsive. The difference is very big. So now I debug all my projects only in 64-bit Lazarus. ---------------------------------------------------------------------- Martin_fr · 2019-01-03 12:42 Quote from: r2r3 on January 03, 2019, 10:21:15 amfpDebug seems to crash for me. Which Lazarus? 2.0RC3 or revision? How to reproduce? ---------------------------------------------------------------------- Martin_fr · 2019-01-03 15:50 I run your "printf" example. (using lldb 6.0.1 / the 7.x downloads seem to come without lldb) LLDB indeed steps into the printf call. That is despite the IDE sending a "step over" (I checked). I don't know why lldb does this. But it can't be fixed in the IDE. You can set a breakpoint in the next line and use F9. But that is of course extra work. I also run the example in FpDebug, and that worked fine for me (using Lazarus trunk) ---------------------------------------------------------------------- Martin_fr · 2019-01-05 15:03 Just another update. During testing (lldb 6.0.1). The 64bit lldb, does not show any stack. Only the topframe is visible. Also watches/locals only work for the top frame. The 32bit version has a working stack. But when selecting lower stack frames, it does not always respect that when returning register values for that frame. (the exact conditions are not clear). Therefore (using lldb + fpdebug) locals and watches for other stackframes may show incorrect values. The lldb only (no fpdebug) 32bit version may not be affected. Not tested. -- Generally the lldb only (no fpdebug) versions are a by-product of the "fp+lldb" debugger. So they receive minimal support. ---------------------------------------------------------------------- fasdfasdfasdfasdfasdf · 2019-01-19 20:58 GDB on QTCreator is super super fast. Almost instant. On Lazarus it takes up to 5 seconds.  Stepping through code is also faster in QT Creator. Really bizarre. You can actually debug FPC code inside QT Creator and it is really faster. But it's only partial. ---------------------------------------------------------------------- Martin_fr · 2019-01-19 22:41 Quote from: r2r3 on January 19, 2019, 09:58:30 pmGDB on QTCreator is super super fast. Almost instant. On Lazarus it takes up to 5 seconds.  You are talking about: 1- the time it takes to start debugging (when you compile and run) 2- evaluation of watches ? The goal of the integration of gdb, is to show the "best" values possible. GDB has a limited pascal understanding, and sometimes it needs help from the IDE. This means the IDE sends extra commands to GDB. Some of those are sent in advance. Eg, to test how the specific GDB on your system interacts with the specific app you have compiled by the specific version of fpc. Some of that could be done in a more optimized fashion. But overall some of it cant be avoided. Or well it can, but then maybe a watch like MyDynArray[1].SomeRecord.Foo would return an error. (That is from memory, so maybe it was a similar expression... There are different pascal expressions that depending on the version of gdb/fpc may not work in gdb.) IIRC There are even case where just access to class members (fields/var) would not work out of the box. Most of this is lacking updates for newer versions, and maybe some of it could be faster with newer versions, but it is a huge job... 1) As for start up One of the big chunks of time is setting up all environment vars. But: If you do NOT "reset debugger after each run" then this is only the first time you start an app, or if you make changes to the env- vars. Also the default installer comes with an older gdb. Newer gdb may be faster. You can get them on our sourceforge site (for win32/64). This is especially if your app has a lot of debug info. Like if you compile the IDE itself with debug info (over 100.000kb of debug info). Therefore, if you do not need to debug lcl or packages, make sure to disable debug info for those. That can speed up both: -linking (part of compile) -start up time of gdb 2) watch eval Not much that can be tuned. However in Lazarus 2.0 some options were added. They help to prevent gdb to crash on out-of-mem. But they do add yet more time consumption.... To at least keep the current timing, on the Tools > Options > Debugger page, in the property grid: Find the two values with GDB....ValueMemLimit in the name, and set them all to equal values (eg  128000). Do the same for the two Max....LenghtForStaticArray values. In any case, if you are looking for speed, I do suggest to switch to Lazarus 2.0 (or currently the RC3, but some fixes are after RC3) and use FpDebug Install the package LazDebuggerFp and set the debugger type (Tools > Options) to fpdebug. (the path to gdb will be empty / actually it is ignored) LazDebuggerFp is a good deal faster. And at least on Windows it appears fairly stable (I use it a lot). On Linux it is good, as long as your app is single threaded. (fixes for that will - once made - only go to trunk) FpDebug is not yet feature complete. But all the main stuff (stepping, breakpoints, watches, locals, threads (on win)) are there. Some examples of missing things: - watchpoints - debug history - support for some types in the debug inspector - modify variables in the target If FpDebug still crashes for you, then consider helping by reporting (reproducible) bugs. Note that in 2.0rc3 it still has a good chance of crashing when you pause on a "begin" or "end" line (most outer begin/end of a function/procedure). This has been fixed (for all currently known cases) after RC3. A final fix for that will require a bigger rework, and at some time be done in trunk. btw, with fpdebug, you probably should use "reset after each run" (checkbox in options) I don't mind adding a faster, basic gdb, that just returns the pure gdb results, with no extra work in the IDE. But that would require someone else to write it. I already have half a dozen debuggers in the IDE that take my time. So I really can't find the time to write yet another. ---------------------------------------------------------------------- Martin_fr · 2019-01-21 00:55 Quote from: r2r3 on January 19, 2019, 09:58:30 pmOn Lazarus it takes up to 5 seconds.  HDD or SSD? That is your project: project1.exe I have done a few tests, with a default empty Form1 project. Starting process in the debugger (That is the 2nd, or later run of the debugger, with "Reset after each run" disabled) - project on HDD: 4-5 Sec - project on SSD: 2-3 Sec If you are on 2.0RC => Apply the changes from r60130 Debugger: remove some active logging Logging can slow things down. It accidentally slipped in. Also you may want to set the following option in the debugger options: DisableLoadSymbolsForLibraries => Set to True, may save up to 0.5 secs (estimated, I did not implement measuring) And disable everything for the "event log". Though I did not notice a difference here. You may also want to use GDB 8.2. For big projects, it can save some time. But even more time is saved by disabling debug info for packages (assuming you only debug code in your project) You can force this via "additions and overrides" (search the wiki if you need more info) Add target: * with a custom option: -g- and target: #project with a custom option: -gw -godwarfsets The project must be after the *. With all of that, the form1 project starts in maybe 1.5 to 2 secs (estimated from looking at my watch)