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

[meister via lldb-dev]

Common Lisp is a different kind of language - it’s never supposed to seg fault. :-)

It’s a dynamic language that I am compiling to llvm-ir and using to call and drive C++ libraries.
The integrated debugger takes over when an error is signaled and it should allow the user to view the stack, inspect arguments and lexical variables and to unwind the stack and proceed indefinitely.

Now, I’m generating llvm-ir and that runs just like C++ generated llvm-ir.  
My stack traces are C++ style stack traces with stack frames from C++ functions interleaved with stack frames from Common Lisp code.
I use C++ exception handling to unwind the stack in Common Lisp and that enables RAII to keep working.

I’m kind of caught between worlds.  I already have a debugger that can view stack traces - but to achieve it I’ve had to insert calls at the entry and exit of all Common Lisp functions to spill register arguments and to maintain a shadow stack of stack frames for Common Lisp functions.  This is a huge barrier to inlining and optimization.  I also generate DWARF metadata but I can’t access it without going through lldb.
That’s why I’d like to incorporate the lldb C++ API’s.

Best,

.Chris.



> On Aug 29, 2017, at 2:48 PM, Jan Kratochvil <jan.kratochvil at redhat.com> wrote:
> 
> On Tue, 29 Aug 2017 20:17:57 +0200, meister via lldb-dev wrote:
>> (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.
> 
> For catching runtime errors on Linux you should just SEGV and system crash
> reporter will catch it, backtrace it, bugreport it etc.  At least ABRT in
> Fedora/RHEL case, other distros have some similar tools for that.
> 
> And developers should run the program under debugger in the first place.
> 
> 
> Jan