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

LLDB debugger low level interface investigation results

(1/6) > >>

AndrewCot:
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.
--- Code: ---// 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;
}



--- End code ---

MortenMacFly:
Thats interesting.
Strange the way they take with  LLDB/MI... but probably there is a good reason for it.

BlueHazzard:
Interesting. Thank you for reporting.
Are the calls (for example process.Continue();)  blocking or not blocking?

eranif:
Hi C::B team,

I rarely post on this forum, but I couldn't help noticing the discussion about LLDB (and the path that I took with CodeLite)
However, I would not take this path today. In fact the future of the debuggers, is similar to code completion: via dedicated small servers.

Today, most of the IDEs (including CodeLite) is using LSP (Language-Server-Protocol) for getting code completion via various implementations (clangd, rust-analyzer, pylsp etc)

The same revolution is taking place for the debuggers using the DAP protocol (Debug-Adapter-Protocol)

https://microsoft.github.io/debug-adapter-protocol/

I would recommend your to consider this path before investing time in using LLDB API directly


Eran

AndrewCot:
Eran,

Thanks for the info.

I did not investigate the DAP, but will now have a look.

Thanks,Andrew

 

Navigation

[0] Message Index

[#] Next page