Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

LLDB debugger low level interface investigation results

<< < (3/6) > >>

Thanks for the post as it will help.

I looked at your repo's a long time ago and seen it was a few years old and did not spend allot of time figuring out how it worked. I will have another look and spend time figuring it out.
I did not see that MSYS2 has the lldb-vscode as I downloaded the official release for it from the src git repo and started it. I will switch to the MSYS2 version.


I have just successfully modified my local C::B for the following:a) Created a debugger_WXDAP.dll that is the dap dll and right now is in the same directory as the codeblocks.exe.
b) Created a new debugger plugin debugger_dap.dll that is wired in like the other debuggers (GDB and GDB/MI).
c) The changes worked enough and I have wired up enough so that when I run a program to debug it in the C::B GUI the connection through the debugger_WXDAP.dll works and I get debug output on the lldb-vscode.exe. I have only wired up the connection and the events only log to the debug log on the C:B gui.

There is still a huge amount of work to do and it will take a while to go from where I am to

If I find anything I will create issues and/or PR's against the github repo.

Thanks very much for your help and advice on the DAP and the DLL.

this looks really nice, great work.
Also thank you for sharing here in the forum!

I now have some rudimentary debugging on an exe in C::B working as follows:

* The exe is loaded via the DAP dll using the new DAP debugger plugin.
* The exe can be started and run with a breakpoint set on main() as default in the debugger plugin for the time being (I do not have any persistent breakpoint or watches etc)
* I can use step to the next line. I have wired up most of the other step features, but have not tested them.
* I can set one line break point in the file and then run to the break point. The DAP break point API works on a file basis with array of breakpoints for the file, which is different to the GDB/MI code I started with and as such I need to refactor the way the breakpoints are stored in the debugger plugin.
* I have the call stack partially working in that it shows data and some of it looks right, but some does not.
* I can stop debugging and start debugging again.Things not in the list above are not working. 

I will be working on the following in the order listed, unless I hit something or need a break on the work:
* Add support for multiple line break points in a file
* Wire up simple watches. Aka add to watch dialog only and update as you step / run the debugee
* Enable break point and watchs to be persistent from the GDB/MI debugger plugin.
* Get the call stack working correctly
* Wire up starting the LLDB debugger exe when you start debugging. (commented out at the moment so I can see what is happening on a command prompt)
* Migrate/test on Linux
* Migrate/test on MacOS
* Use in anger to fix C::B issue(s) on MacOS. In other words use it in the real world.
* Add features required to make debugging better.
* Update ticket 1114 to add support for the CLANG compiler to detect debugger and add it as a debugger automatically.

Wow!! It nice to see this happening.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version