Forum > Lazarus
New debugger for Mac based on lldb (Call for testers)
Martin_fr:
With the Lazarus Release Candidate 1 for 2.0 a new debugger for Mac users has been shipped.
It is based on LLDB, which is provided by apple and is ready to use. So there should no longer be a need to build and codesign gdb.
As the LLDB integration is all new, it needs a lot of testing. So this is a ...
call to all Mac users:Please test the new LLDB based Lazarus debugger.
To test the new debugger, please download the Lazarus 2.0RC1.
- Open the IDE and install the package "LazDebuggerFpLLdb".
It should be in the list of available packages, but if not it is in components/lazdebuggers/lazdebuggerfplldb
Make sure to use the one with "Fp" in the name. (There also is LazDebuggerLLdb, but it is not as good.)
Restart the IDE.
- Go to 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.
(lldb comes with the tools from Apple; and as such it is already codesigned by Apple).
To report any problems:
Start Lazarus from a shell with the following command line (replace pathes according to your installation):
You may need to use startlazarus, or specify the re-build lazarus which may be in your home folder / pcp.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---/path/to/lazarus/lazarus.app/Contents/MacOS/lazarus --debug-log=/path/to/yourfiles/laz.log --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,FPDBG_DWARF_ERRORS,FPDBG_DWARF_WARNINGS,FPDBG_DWARF_VERBOSE_LOAD,FPDBG_DWARF_DATA_WARNINGS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS,DBG_THREAD_AND_FRAME,DBG_ERRORS
EDIT ON 16 DEC 2020:
Please also add to the list of keywords for logging
,FPDBG_COMMANDS,FPDBG_THREADS,FPDBG_QUEUE
Attach the log file after reproducing the error.
--------------------
EDIT:
If you have a lot of units with debug info (eg all of LCL with debug info) you may have to increase ulimit.
https://bugs.freepascal.org/view.php?id=34467(should be fixed in RC3)
Known Issues in the 2.0 release that are fixed for 2.0.2:
Svn users can update in fixes branch. None svn users can download replacement files via http as directed below.
* Single stepping, may sometimes step the wrong thread (if paused in a multithreading app)
To apply the fix in Lazarus 2.0.0 go to https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60339 and download the 2 files. You can replace the entire files in your 2.0.0 install. Rebuild the IDE and restart.
* Fix a crash for local/watches on begin/end of procedure.
To apply the fix in Lazarus 2.0.0 go to https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60353 and download the file. You can replace the entire files in your 2.0.0 install. Rebuild the IDE and restart.
* Fix several issues when debugging multi-threaded apps:
- Eval watches,hints,locals according to selected thread (and stackframe)
- Select correct thread at breakpoint
- Select correct Stackframe for thread, when switching threads
To apply the fix in Lazarus 2.0.0 go to https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60436 and download the file. You can replace the entire files in your 2.0.0 install.
In order for this to work you must also install the file lldbinstructions.pas from for revision=60339 / 1st in this list. (the file lldbdebugger.pas must be taken from this changeset (revision=60436): lldbdebugger.pas@60436 includes lldbdebugger.pas@60339.
Rebuild the IDE and restart.
* Detect and warn, if debugger path points to gdb instead of lldb (wrong config after upgrade)
* Improved handling of lldb warnings during startup. Do not terminate debug session, if warnings where issued.
* If debug session stops due to error, close debugged application. Otherwise it could not be terminated.
* Speed up single stepping. (remove/reduce lag before next step could be executed)
*
Known Issues that will be in 2.0 release:
* Small remaining risk of: A workaround (for currently known cases) has been applied. (r59895)
Evaluating of local var and param while paused on procedure/function begin or end line may cause crashes.
This applies to Locals/Watches/Evaluate/... views.
Currently the problem is know for variable len type data (string/dyn array), including structures containing such types.
See https://bugs.freepascal.org/view.php?id=34746
* Strings and Arrays are limited to a max len of 5000 / 3000. Currently this is not configurable. Sometimes less. Nested arrays are limited to just the first few items.
* Low risk of PChar, WideStrings, (maybe AnsiString in Dwarf 2) may be cut off, even if below there max len limit. The Debugger sees WideString as PWideCHar and has to guess how far to look for the terminating #0. The guess is adjusted in steps, and may miss the correct len.
Known Issues in RC3 fixed for 2.0:
* Nested array (including dyn array in structures that are nested in arrays, may not display correct.
This applies when the any of the inner arrays is a dynamic array. All indexes may show data from the first index.
This problem may be worse for dwarf-3, but can appear with dwarf-2 too. Fixed r59962 and other revisions before
* Some Global values may return wrong results. (Not clear under which conditions. Possible such variables that are not accessed within the unit that declares them, but only from outside the unit... But not sure) Fixed in r60015
* A 32bit IDE may have issues with some watches when debugging a 64 bit target. (The other way round should be ok, after r60041) fixed in r60085
For the testcase please see: http://forum.lazarus-ide.org/index.php/topic,42869.msg307134.html#msg307134
More on "debug info type" (dwarf): http://forum.lazarus-ide.org/index.php/topic,42869.msg311363.html#msg311363
dbannon:
Martin, forgive my ignorance, I am unsure of how gdb / LLdb interact with heaptrc.
Specifically about memory leaks, will using LLdb give me the same sort of info on the Mac I am used to getting on Linux ?
Even if not, this is an astounding step forward. We loose so many potential Mac user who just read through those code signing instructions and shake their heads sadly...
Davo
Cyrax:
GDB/lldb have nothing to do with heaptrc functionality. Heaptrc uses compiler generated debug info to display the lines and their numbers where the leak happened.
Martin_fr:
Heaptrc, works without the debugger.
GDB/LLDB is for setting breakpoints, single stepping, inspecting variables.
The LLDB based does not yet have all the features. E.G. "step to cursor" does not yet work. And the disassembler may not always work.
As for properties (with getter function): They can not be watched, same as under gdb.
Josh:
Hi
Had a quick look and did not see a folder for mac osx x86_64 to test? Just OSXi386
Am I missing something?
Navigation
[0] Message Index
[#] Next page