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

[meister via lldb-dev]

Greg,

We are developing a compiler for Common Lisp that uses LLVM as the backend and interoperates with C++ - it has its own REPL and built in compiler.   
Our compiler generates llvm-ir that we link directly with llvm-ir generated from the C++ code using LTO.
I’ve exposed much of the LLVM C++ API and Clang ASTMatcher C++ API for automatic analysis and refactoring of our C++ code.

The Python API’s are not that useful to us.   
Although - maybe launching lldb as a separate process to get the backtrace with a python script may be a reasonable thing to do - if that’s all that I want to do.
I’d also like to explore accessing lexical variables and setting breakpoints and watchpoints using the C++ API.
The C++ API’s - they are much more straightforward to work with for us.

I am already using ‘backtrace’ - but I don’t get function arguments with that sadly.

Best,

.Chris.




> On Aug 29, 2017, at 2:30 PM, Greg Clayton <clayborg at gmail.com> wrote:
> 
> 
>> On Aug 29, 2017, at 11:17 AM, meister <chris.schaf at verizon.net <mailto:chris.schaf at verizon.net>> wrote:
>> 
>> 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?
> 
> You can do the first, not the second. LLDB attaches to processes via ptrace which means it will suspend all threads in the process it is attaching to, so you can't do this to yourself. Forking another process will do the trick. You can also do all of this from Python! The entire LLDB API is exposed to python and python can be used on the command line from a python script, or from within LLDB itself by using the "script" command which drops you into an embedded python interpreter.  On Mac, if you know Xcode is installed, you can just run a python script to do what you need. Let me know if this sounds interesting. On linux, you could use the installed lldb to do the backtraces using a python script as well.
> 
>> 
>> (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?
> 
> Other APIs not in LLDB if you must stay in process:
> 
> $ man backtrace
> 
> If you launch another process, it will be able to backtrace your current process and you can use LLDB's APIs.
> 
>> 
>> (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?
> 
> You might think about locking onto they latest public release of lldb. This might be more stable than just grabbing top of tree.
> 
>> (b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my binary release?
> 
> Yes. You might think about using python and just using the installed LLDB? 
> 
>> (c) On OS X - can I use the builtin lldb library? I haven’t checked if header files are available.
> 
> Header files are not available, but our API is stable. You could theoretically link against the top of tree LLDB.framework and tell it to use the system version (in /Applications/Xcode.app/Contents/SharedFrameworks, or somewhere for linux)
> 
>> (d) On Linux - can I use package manager installed versions of lldb? 
> 
> Yes. If you go this route, I would suggest using a python script. Then you don't even need to link against 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.
> 
> That sounds like it can work. If you want to actually use the debugger when there is an issue, you will not want to use python. But if you are just trying to get backtraces, then a  python script might work, plus it will insulate you from having to link against lldb.
> 
>> Thank you!
> 
> No worries, we are here to help!
> 
> Let me know what you think about my above comments,
> 
> Greg Clayton
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170829/a8d60f0a/attachment-0001.html>