[lldb-dev] Linking the lldb C++API/library with other projects

meister via lldb-dev lldb-dev at lists.llvm.org
Tue Aug 29 11:17:57 PDT 2017


Dear Greg,

Thank you very much for your detailed and thoughtful response.

A couple of followup questions based on what you said:

(1)  You say: "since LLDB can't be used to backtrace itself…"
Do I (a) need to fork another process and call the LLDB API’s to get backtraces for the original process or (b) can I simply create another thread and call LLDB API’s to interogate other threads using the SBThread API?  Or can I do both of these?

(2) When you say "so if you are looking to backtrace things in your current process you should probably use other APIs.”
By "other APIs” do you mean other SBxxxx class API’s like SBThread? or do you mean other API’s entirely? If the latter could you give an example?

(3) If I call LLDB from my code like this - how would you recommend distributing this?

(a) When building from source should I have the build system pull lldb from a the llvm github repo?
(b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my binary release?
(c) On OS X - can I use the builtin lldb library? I haven’t checked if header files are available.
(d) On Linux - can I use package manager installed versions of lldb? 

For some of these I realize that I'll have to do some legwork to figure out what is available from package managers etc.

(4) Since I have to debug from a separate process does the following sound reasonable.
(i) My program detects an error and enters into its debugger.
(ii) It forks a debugging process and that interacts with the user who uses it to debug the main process.
(iii) The debugger process shuts down and the main process continues.

I’d be doing this from within a Common Lisp programming environment called SLIME in Emacs - I have no idea right now if it’s possible to have the integrated debugger in SLIME work with a separate debugging process. Fun, fun, fun.

Thank you!

.Chris.




> On Aug 29, 2017, at 1:18 PM, Greg Clayton <clayborg at gmail.com> wrote:
> 
> 
>> On Aug 29, 2017, at 8:21 AM, meister via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 
>> Does anyone have pointers on how to link the lldb C++ API/library with another project that uses a command line driven build system?
> 
> You can always use "xcodebuild" if you need to for Mac builds:
> 
> lldb:
>    cd /tmp/lldb
>    xcodebuild -configuration Release
> 
> For all others cmake + ninja is the preferred method. Mac builds don't use cmake + Ninja as we let Xcode make the LLDB.framework. A framework is a directory that contains both the shared library and all public header files needed in order for people to link against the LLDB shared library. It is possible to build LLDB using cmake + ninja on Mac, but you end up with a lldb.dylib shared library instead of a LLDB.framework. The nice thing about the LLDB.framework being a directory is that it gives us a place to put all of the support binaries that go along with LLDB: lldb-server, darwin-debug (mac only), lldb-argdumper, header files needed by clang for expression parsing, python modules, and more.
> 
> You can see all that is in the framework by doing:
> 
> $ find /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework -type f
> [text deleted]

> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc/Contents/Info.plist
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc/Contents/MacOS/RootDebuggingXPCService
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc/Contents/version.plist
> 
> 
>> 
>> We would like to incorporate the lldb C++ API/library into our Common Lisp programming environment to get better backtraces and debug info in a portable way (OS X and Linux).
>> 
>> lldb is written as a library and in principle this should be possible.   
>> In practice I’ve had a tough time getting started.  I can build lldb with Xcode on OS X.
>> This is not a criticism - I know resources are limited.  The documentation for using the C++ API of lldb are thin and examples are few to non-existent.
>> I don’t need a lot of help - I would just like a starting point.
> 
> To start with I would recommend:
> 1 - build with Xcode on Mac and link against the LLDB.framework
> 2 - build with cmake + ninja on all other systems and link against the liblldb.so. Then you will need to package lldb, liblldb.so and all needed extra files (lldb-* from the build directory, the python modules, etc) in a place that LLDB can find them (usually all executables in the same directory, python module in the same directory as liblldb.so (please correct me if I am wrong on this linux folks!)
> 
> 
>> I’m developing CANDO, an implementation of Common Lisp that uses llvm as a backend  (github.com/drmeister/cando)
>> I have extensive experience using the llvm/clang API’s within CANDO.
> 
> That is good, then you will already understand the make + ninja output build directory that will contain lldb and liblldb.so for other systems.
> 
> Once you have linked against the LLDB.framework or liblldb.so, then you need to call the following static class function:
> 
> using namespace lldb;
> SBDebugger::Initialize();
> 
> before calling anything else. This is the call that initializes all LLDB plug-ins and gets everything ready for more. One things are initialized you will want to create a lldb::SBDebugger object using:
> 
> bool source_init_files = true;
> SBDebugger debugger = SBDebugger::Create(source_init_files);
> 
> The debugger object is what owns the command line interpreter (the "(lldb)" prompt) and all targets. 
> 
> If you are going to want people to use a command line interface to lldb, create a FILE for stdin/out/err and pass them to the debugger:
> 
> bool transfer_ownership = false;
> debugger.SetInputFileHandle(stdin, transfer_ownership);
> debugger.SetOutputFileHandle(stdout, bool transfer_ownership);
> debugger.SetErrorFileHandle(stderr, bool transfer_ownership);
> 
> It doesn't sound like you need the command line interpreter for backtraces, but I mention it just in case. If you do plan on using it, let us know.
> 
> Now you can create and use targets by creating a lldb::SBTarget object using the "debugger" instance you have.
> 
> Note that LLDB can't be used to backtrace itself, so if you are looking to backtrace things in your current process you should probably use other APIs.
> 
> Let us know if you have any questions.
> 
> Greg Clayton
> 
> 
> 
> 
> 
> 



More information about the lldb-dev mailing list