Recent

Author Topic: lldb on windows?  (Read 9358 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: lldb on windows?
« Reply #15 on: January 03, 2019, 01:42:12 pm »
fpDebug seems to crash for me.

Which Lazarus? 2.0RC3 or revision?
How to reproduce?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: lldb on windows?
« Reply #16 on: January 03, 2019, 04:50:34 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: lldb on windows?
« Reply #17 on: January 05, 2019, 04:03:26 pm »
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

  • New Member
  • *
  • Posts: 45
Re: lldb on windows?
« Reply #18 on: January 19, 2019, 09:58:30 pm »
GDB on QTCreator is super super fast. Almost instant.
On Lazarus it takes up to 5 seconds.  :o

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.
« Last Edit: January 19, 2019, 11:36:00 pm by r2r3 »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: lldb on windows?
« Reply #19 on: January 19, 2019, 11:41:06 pm »
GDB on QTCreator is super super fast. Almost instant.
On Lazarus it takes up to 5 seconds.  :o

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.
« Last Edit: January 19, 2019, 11:44:36 pm by Martin_fr »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: lldb on windows?
« Reply #20 on: January 21, 2019, 01:55:49 am »
On Lazarus it takes up to 5 seconds.  :o

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)

 

TinyPortal © 2005-2018