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 <clayb...@gmail.com> wrote: > > >> On Aug 29, 2017, at 11:17 AM, meister <chris.sc...@verizon.net >> <mailto:chris.sc...@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 > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
