I’ve pondered integrating the REPL into LLDB - but what I really want/need is
for all of this to run within SLIME - and I don’t know enough about it to do
that.
I do know how to talk to complex C++ API’s from Common Lisp - hence my line of
questioning.
I’ll think on that more though. What you describe might be appropriate for an
interactive development mode. Thank you.
Common Lisp users have certain expectations that they will get backtraces with
arguments and be able to interactively inspect arguments and lexical variables
using the interactive SLIME Debugger interface in Emacs. The more I use that
interface - the more I fall in love with it.
I’m trying to figure out where the best compromise is.
Best,
.Chris.
> On Aug 29, 2017, at 3:03 PM, Greg Clayton <clayb...@gmail.com> wrote:
>
>
>> On Aug 29, 2017, at 11:41 AM, meister <chris.sc...@verizon.net> wrote:
>>
>> 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.
>
> You might think about integrating your REPL directly into LLDB? That is how
> we did it with Swift. Then you get everything for free:
> - debug your REPL code by setting breakpoints
> - when a REPL code snippet crashes, see the backtrace!
>
> You might search for a Swift REPL demo and see what you think.
>
>
> Below is an example of the Swift REPL that is built into LLDB:
>
> $ swift
> Welcome to Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42). Type
> :help for assistance.
> 1> func foo() -> Int {
> 2. return 12;
> 3. }
> 4.
> 4> foo()
> $R0: Int = 12
>
>
> Any line that starts with ':' is a LLDB command. Below we set a breakpoint on
> line 2 of our REPL code:
>
> 5> :b 2
> Breakpoint 1: where = $__lldb_expr3`__lldb_expr_2.foo () -> Swift.Int + 4 at
> repl.swift:2, address = 0x00000001000c5014
>
> Now we can call foo() and hit our breakpoint:
>
>
> 5> foo()
> Execution stopped at breakpoint. Enter LLDB commands to investigate (type
> help for assistance.)
> Process 40238 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> frame #0: 0x00000001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
> 1 func foo() -> Int {
> -> 2 return 12;
> 3 }
> 4 foo()
> 5 foo()
>
>
> Note we drop into the LLDB command prompt. We can view variables, backtrace,
> etc. Here we just continue:
>
> (lldb) c
> Process 40238 resuming
>
> Now we are back in the REPL:
>
> 6> func bar() -> Int {
> 7. return foo() + 23;
> 8. }
> 9> bar()
>
> We are going to call "bar()" which will call "foo()" so we will hit the
> breakpoint again...
>
>
> Execution stopped at breakpoint. Enter LLDB commands to investigate (type
> help for assistance.)
> Process 40238 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> frame #0: 0x00000001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
> 1 func foo() -> Int {
> -> 2 return 12;
> 3 }
> 4 foo()
> 5 foo()
> 6 func bar() -> Int {
> 7 return foo() + 23;
> (lldb) c
> Process 40238 resuming
> 10>
>
>
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
