you missed inserting [ quote ] ... [ /quote ] tags...
I don't understand the internals of the Lazarus IDE or debugger code, but am trying to rebuild the Lazarus IDE in debug mode -- with the hope of doing some debugging through lazdebuggerlldb.pas -- though at the moment packages don't seem to be generating the debug output needed to stop at breakpoint source code lines.
In many cases it is enough, to open menu: Tools > Configure build Lazarus => There you can add options for compiling the IDE. You can use -gw3 (dwarf3). (Should that give unexpected trouble (errors produced by lldb), then use only -gw (dwarf2)).
Also add -O- to disable optimizations, which could interfere with the debugger.
A good set of options:
-gw3 -O- -gh -gt -Criot
Not all package follow this. You can open individual packages from the menu "Package". (If you open LazDebuggerFPLldb first, then you can open LazDebuggerLldb from that package / might be quicker).
Each package has a button "Options". There you can set any options you want.
Both the LazDebugger...Lldb packages should have "$(IDEBuildOptions)" in the "costum options" section of their options. This means they follow the global options.
While usually not needed, if in doubt, in "Configure build Lazarus" choose the "clean all" option.
To debug the IDE, inside another IDE:
- Open the project (inside the lazarus install folder) ide/lazarus.lpi
- Press F9 to run
This will not correctly recompile changes that you made (even if it looks like). If you made changes always recompile from the Tools menu.
If you debug the IDE a lot, open the project (ide/lazarus.lpi), go to menu Run > Run Params, and add as "command line parameters"
--primary-config-path=/path/to/empty/folder
This allows you to have a separate global config for the debugged IDE.
You can also add any --debug-enable, that you need for logging.
(With your knowledge and experience, of course, your efficiency is superior but I thought I'd give this a shot since the OSX environment seems likely to be the issue for the laz lldb code?)
The LLDB debugger was written only for the OSX environment. All other OS are better of with GDB.
Yet I myself am a Windows/Linux user. So most of my development happens on those platforms. I have access to a MAC, which I use for dedicated testing.
But since I do all my normal debugging on Win/Linux, the testing of LLDB on Mac from my side is limited to a few dedicated test runs.
So for stress testing, I have to relay on feedback. And extra help is always welcome.
I will try to provide information re: the stack though I'm not sure how exactly to do that.
If you run a logfile --debug-log as specified in the very first post of this thread, then the data will be included in the logfile. All you need to do, is to keep the IDE's stack window open, so the IDE will need the data, and get it from lldb.
The same applies to the register window (from menu View > Debug Windows). Just leave it open.
The stack window has a copy button, to copy its content, but that will not be needed.
What I meant is:
- You may be executing code in FormCreate (or any function / Since you step through it, you know the functions name)
- It makes a call like "Top := 7", you STEP-INTO it.
You are now in TControl.SetTop function. You do know it was called from FormCreate.
But if you look at the stack, it will show
SetTop
SomethingInTheLCL
The function FormCreate is missing from the list. Shoud that case happen, then simply say so.
My last assembly language programming (mostly 8080 and 8086) was back in the 1980's and then moved onto "C/C++" and since I've mainly worked in applications-level programming since then, I rarely even think about stacks :-(
Well all I mean is the high level representation of the Stack. Just look at the Stack window.
I will do what I can to put together a relevant logfile.
1) You want to continue stepping, in the thread that was interrupted by the breakpoint?
Yes
But (unless you do changes in the thread window), stepping happens in a different thread? (main thread? or thread in which previous breakpoint occured?)
Yes, using the capablilty you showed me of being able to send a command directly to lldb, after the breakpoint successfully works, I can select/set the source code thread. Only then can I use F7 and/or F8 (from the IDE) successfully. Not sure what you mean by the "main thread" (IDE or my source) but stepping does not occur in my source code thread -- shown by the assembler window not longer showing my source code as it did when the breakpoint occurred. Without lldb intervention to select my thread, after doing an "IDE" step (F7 or F8), the assembler window shows some other section of code. (I'll give you attachments to show this.)
So you send for example
thread select 5
to the debugger.
And then you press F7 which sends "thread step-in"
Also, when you reach the breakpoint, in the thread window, is the correct thread selected?
Haven't looked at the "thread window" -- but the assembler window at the breakpoint stop is correct (showing my source code lines). However, unless I then reset the thread to the source code thread directly sending the "select thread" command to lldb, any stepping (F7 or F8) does NOT step through the source code -- and appears to step through some other thread (though if I F9) things proceed again to the next breakpoint.
Ok that answers the question I did ask 2 lines above....