LLDB debugger low level interface investigation results

[AndrewCot]

Update:

• Done - Add support for multiple line break points in a file
• Done - Wire up simple watches. Aka add to watch dialog only and update as you step / run the debugee
• Done - Enable break point and watchs to be persistent from the GDB/MI debugger plugin.
• Done - Get the call stack working correctly
• Done - 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)
• Build issues Migrate/test on Linux
• WIP - 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.

I have finally got the code building and the plugin loading on Mac. Next day or two I will see about configuring the plugin and testing it on the Mac.

[AndrewCot]

Great news...

• DAP debugging working on Linux
• DAP debugging working on MacOS - see attachment

Now the not so great news. There are some issues on the Mac:

• The code to run the following does not work, so I need to manually run it and comment out the code:

                  /usr/local/Cellar/llvm/14.0.6/bin/lldb-vscode -port 12345

• I have had C::B crash when doing some debugging

The source code for the DLL and plugin is available from the following repo, but be aware that it is only for the hard core developers and WILL change and is NOT production quality or even beta quality:
    https://github.com/acotty/CB_Debugger_DAP_Plugin         
In the next few hours I will do a major update on the following repo to include all of the changes so you can use it to build C::B with the plugin:   https://github.com/acotty/CodeBlocks_Unofficial_Testing
BTW There is an issue with the main workspace I am using where I have specified the plugin depends on the DAP DLL, but the DAP DLL does not get built before the plugin so the plugin link fails.
Note: Working is used very very very loosely above.

[BlueHazzard]

Great work!
Nice list of features you have there!

>The debugger is NOT able to debug itself
I am quite curios why this is so? What is the problem? Network port collision?

[AndrewCot]

>The debugger is NOT able to debug itself
I am quite curios why this is so? What is the problem? Network port collision?

I have not got that far yet as it's part of the following dot point, but I will be giving it a go later today:

• Use in anger to fix C::B issue(s) on MacOS. In other words use it in the real world.

Can you let me know where I put the info that it cannot debug itself or inferred this so I can correct it or try to correct it.

I will need to use two different network ports for the DAP debugger, one for the "master" C::B to use to debug the C::B debuggee and then another one for the C::B debuggee to debug a hello world app.

[BlueHazzard]

CODE::BLOCKS DAP DEBUGGER PLUGIN
Description

This GitHub repo contains the source code for a Code::Blocks DAP debugger plugin. The debugger is NOT able to debug itself and is a NOT viable replacement for the existing GDB plugin at this point in time.

in the read me. I was asking this, because an earlier version of codeblocks had the same problem. You could not debug codeblocks running gdb. I think this was because some fancy PID detection. But it was fixed some time....

[AndrewCot]

Thanks. I have updated the readme.md

I got side tracked onto the debugger detection on startup and it has taken allot longer than I expected and have not got to using the plugin to debug itself.

[AndrewCot]

The DAP debugger can debug itself, so long as you use different network ports. I just finished testing this.

If you are one of the people who have cloned the https://github.com/acotty/CB_Debugger_DAP_Plugin repo then please pull the changes as I fixed a nasty issue in the code today where I commented the OnIdle(..) from the GDB/MI as I thought the code was non needed, but the event.Skip(); was as it causes compilation issues. Go figure!!!!

[Pecan]

...where I commented the OnIdle(..) from the GDB/MI as I thought the code was not needed, but the "event.Skip();" was as it causes compilation issues. Go figure!!!!

That's caught me a couple of times also.

wxWidgets ends processing any event if there is no Skip() called. Events are pass on to other users only when a call to Skip() is done.

It's especially important to issue a call to Skip() from within an OnIdle() event. Else plugins (etal) will never receive their OnIdle event hooked onto async I/O etc.

[AndrewCot]

Update:

• Done - Add support for multiple line break points in a file
• Done - Wire up simple watches. Aka add to watch dialog only and update as you step / run the debugee
• Done - Enable break point and watchs to be persistent from the GDB/MI debugger plugin.
• Done - Get the call stack working correctly
• Done - Wire up starting the LLDB debugger exe when you start debugging.
• Done - Mac Project files now build DLL and plugin
• Done - Linux Project files now builds DLL and plugin
• Done - Linux bootstrap/configure/make process now builds DLL and plugin
• Done - MacOS Project files now builds DLL and plugin
• Done - Macos bootstrap/configure/make process now builds DLL and plugin
• Done - add support for the CLANG compiler to detect debugger and add it as a debugger automatically (compiler config XML changes
• Done - MAcOS update DMG file creation - needed to easily install updates
• Working - by default it captures exceptions on Linux and Mac and if you use Clang64 on Windows (Mingw64 does not work and 32 bit not tested)

Real world usage:

• Use in anger to fix C::B issue(s) on Mac to go through the Mac Tickets. Most seem to be codecompletion issues and
• Add features required to make debugging better

Future:

• Remove the codecompletion from the builds as clangd_client is working better than codecompletion and I have it in my builds. This will resolve a number of tickets.
• Future - Linux update DEB file creation and test

I have started looking a the Mac tickets and found that there is not allot of info on how to reproduce the issues or logs that can be used to analyze the problem when it occurred.... Something devs need to be aware of that even tough you may not look at the ticket you need to ensure that enough info is captured for ad different dev to look at it in a few months/years.

[AndrewCot]

Quick update:
I can now successfully debug C::B from C::B using the DAP debugger on Windows.

The code is available from the following repo:https://github.com/acotty/CodeBlocks_Unofficial_Testing

If you want to try it then you will need to start with the following directories and add the CBP to your workspace and configure your environment to build the two projects:

• src\plugins\contrib-wip\DebugAdapterProtocol
• src\plugins\contrib-wip\Debugger_DAP

To use the LLDB debugger you need to configure your C++ to build with -dwarf-4 instead of -ggdb. GDB can use the -ddwarf-4 debug information.

Next for me to try the code on Mac to see how if it also works w.r.t. C::B debugging C::B.

[ollydbg]

Nice work.

One question(newbie question)

Under Windows, do you mean DAP debugger == LLVM debugger ?

[AndrewCot]

Simple answer : Yes

Additional info: Currently the debugger plugin code auto detects the DAP adapter for LLDB (the LLVM debugger). There is code in the repo to also auto setup the debugger config from the options*.xml file, which is an outstanding SF ticket, which make setting up the compiler and debugger allot easier.

You can run a number of different DAP adapters that then interface to different debuggers for different languages, so it "theory" you could use the DAP debugger plugin to debug say rust or some other language without changing the plugin or C::B code. "theory" is in quotes as in I have no idea if it will or will not work, but this s how VSCode supports debugging different languages without having to change the IDE.

The DAP adapter used for LLDB debugging is the C:\msys64\mingw64\bin\lldb-vscode.exe adapter (please do not try the official LLVM lldb-vscode.exe as it works differently for some reason and I have not looked at why, but it seems that the different LLDB adapters all seem to work differently or have issues/bugs).

[AndrewCot]

Very good news:  *I have succeeded in C::B debugging C::B on Windows and MAC!!!!

On Windows you can now use the following DAP adapters:

• MSYS2 MingW64  C:\msys64\mingw64\bin\lldb-vscode.exe
• MSYS2 Clang64  C:\msys64\clang64\bin\lldb-vscode.exe
• https://github.com/vadimcn/vscode-lldb using the extension\adapter\codelldb.exe file

On the Mac Intel computers you can now use the following DAP adapters (I do not have a M1 or M2):

• LLVM 14.0.6 lldb-vscode  /usr/local/opt/llvm/bin/lldb-vscode
• https://github.com/vadimcn/vscode-lldb using the extension/adapter/codelldb file

For details on setting up the DAP adapters and more info please read the following:
     https://github.com/acotty/CodeBlocks_Unofficial_Testing/blob/master/src/plugins/contrib-wip/Debugger_DAP/Readme_DAP_setup.md
If you have a Mac and need debugging in C::B and are NOT a newbiee then give the unofficial C::B in the following github repo a go:
https://github.com/acotty/CodeBlocks_Unofficial_Testing