I have come to the conclusion that the LLDB debugger docs suck big time compared to the GDB manual that has all of the info in the one spot and at least it explains how things work and gives examples of inputs and some outputs. I cannot find anything like this for LLDB.
I have investigated the different ways of "controlling" the LLDB debugger and they are:- Direct via the command line like the GDB annotations does
- Via a LLDB/MI executable that is no longer part of the LLVM project, but a third party product now.
- Via the LLDB Scripting Bridge API (LLDB SB API)
This is what I have learnt from my investigations:- The LLDB command line is not documented enough to write a plugin easily and it also NOT guaranteed to be stable (aka not change). As such this is not viable IMHO.
- The LLDB/MI has a number of issues and is not fully compatible with the GDB/MI interface that it says it is. I could not get a s simple break point did not work that worked via GDB or via the LLDB command line. As such this has too many issues to consider being viable.
- The LLDB SB API is used by CodeLite and other IDE's. as per the docs "The SB APIs constitute the stable C++ API that LLDB presents to external clients....", so it should not change too much, if at all. Below is a simple example I found on the web and have been able to build and run to test the LLDB SB API.
// https://github.com/llvm/llvm-project/issues/52769#include <lldb/API/LLDB.h>
#include <windows.h>
#include <iostream>
using namespace lldb;
int main()
{
SBDebugger::Initialize();
auto debugger = SBDebugger::Create(true);
debugger.SetAsync(false);
auto const appPath = R"(D:\\Andrew_Development\\Z_Testing_Apps\\Clang_printf\\bin\\clang_Printf.exe)"; // Path to the program being debugged
auto target = debugger.CreateTarget(appPath);
auto breakpoint = target.BreakpointCreateByLocation("main.cpp", 45); // Breakpoint location in the program being debugged
auto breakpointExit = target.BreakpointCreateByLocation("main.cpp", 153); // Breakpoint location in the program being debugged
auto process = target.LaunchSimple(nullptr, nullptr, nullptr);
while (true)
{
process.Continue();
auto const count = breakpoint.GetHitCount();
if (count % 10 == 0)
{
std::cout << count << " "; // We just print the number of times the breakpoint was hit every 100 times
}
auto const countExit = breakpointExit.GetHitCount();
if (countExit != 0)
{
break;
}
}
SBDebugger::Terminate();
printf("EXITING!!!!!!!");
return 0;
}
I am playing with the following library/libraries to plug the DAP interface code hole:
https://github.com/google/cppdap (https://github.com/google/cppdap)
https://github.com/stoianmihail/cppdap-debugger (https://github.com/stoianmihail/cppdap-debugger)
I am using the following DAP LLDB adapter for testing:
https://github.com/vadimcn/vscode-lldb (https://github.com/vadimcn/vscode-lldb)
You will need to extract the https://github.com/vadimcn/vscode-lldb/releases/download/v1.7.0/codelldb-x86_64-windows.vsix (https://github.com/vadimcn/vscode-lldb/releases/download/v1.7.0/codelldb-x86_64-windows.vsix) file using 7zip. I run the adapter using the following command:
adapter\codelldb --port 12345
I have not looked at how VSCode starts the different DAP adapters as I want to get something "working" first. "Working" is load an exe, set a break point on a line, run and hit the break point then run to the end of the hello world type app.
Attached in the 7z is my sample test project inc source that has a a hacked source code sample (LLDB_Client_Test.cpp) that uses bits from both github "cppdap" repos, but the launch step does not return or show anything. It does show the DAP adapter initialize request results, so at least I know the app and DAP adapter are communicating.
The following is a quick guide to build the cppdap library using MSYS2:
The Code::Blocks Debugger Application Protocol debugger plugin uses the following libraries:
* https://github.com/google/cppdap (https://github.com/google/cppdap)
Use the following steps to build the cppdap library using MSYS2:
1. Clone the repo using the following command:
* git clone --recurse-submodules https://github.com/google/cppdap (https://github.com/google/cppdap)
2. Generate the makefile:
bash
cd <path-to-cppdap>
mkdir build
cd build
cmake .. -G "MSYS Makefiles"
3. Finally, build the project:
make
P.S. One thing I spotted yesterday that I need to get my head around is that the DAP protocol launch request spec as it has the following in the spec, so then it makes the IDE only able to launch DAP adapters that it knows about as the launch arguments are specific to the DAP adapter.... I hope this is not the case, but this definitely needs more investigation to see how the launch request is implemented in IDE's.
"Since launching is debugger/runtime specific, the arguments for this request are not part of this specification."
Hope this is helpful.