[Lldb-commits] [PATCH] D71801: [lldb/Lua] Make lldb.debugger et al available to Lua

Mon Jan 6 17:20:07 PST 2020

jingham added a comment.

In D71801#1794758 <https://reviews.llvm.org/D71801#1794758>, @labath wrote:

> +Jim, for his thoughts on debugger+interpreter relationship
>
> I think this is the time to step back and discuss the relationship between debugger and script interpreter contexts...

I actually have no strong opinion about HOW this should be implemented.  Before starting on lldb, I had mostly used Tcl when I was incorporating a scripting language into various tools.  In Tcl, it was natural to make separate independent interpreters.  For instance, the security model for Tcl involved making a secure interpreter that forwarded messages to a shadow - insecure - interpreter that would implement whatever sandboxing you wanted to do.  Tcl interpreters were independent entities with no shared state.  That was the model I was working on when we chose to use Python for lldb, but that's not really how Python thinks of interpreters, and as you note, that caused us a bunch of headaches.

I do feel pretty strongly that to the user, every SBDebugger should have a separate interpreter state.  That really has to be true.  In Xcode, each SBDebugger represents a separate project that the user is debugging, and these often have no relation to one another.  Doing something in one script interpreter and having that affect what should be an entirely independent debugging session would be bad.  Since it is not uncommon for data formatters and Python command modules to use some global state, this could lead to some really frustrating bugs.

It isn't surprising that we have to do different things for each interpreter.  For instance, in Tcl you'd just create a new interpreter and you'd be done.

So my take is that being able to support multiple independent interpreters is a minimum requirement for supporting a scripting language in lldb.  If it can't do that, then we shouldn't try to support it.

I don't know enough about Lua to know whether it passes this (fairly low) bar...

> So, the way I understand the python code, our intention really was to have each (SB)Debugger be independently scriptable, but achieving this with python was hard, as the python state is very global. That's why the python script interpreter needs to jump through a lot of hoops in order to make the Debuggers *appear* to be independent. Here, you're setting yourself up to do the same with lua. That is not completely unreasonable (it's consistent, at the very least), but:
>  a) it may not be possible if lua is not sufficiently flexible to enable faking independent global variables
> 
>    (lldb) script
>    Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>   >>> foobar = 47
>   >>> foobar
>    47
>   >>> d = lldb.SBDebugger.Create()
>   >>> d.HandleCommand("script foobar = 42")
>   >>> foobar
>    47
>   >>> d.HandleCommand("script foobar"))))))
>    42
>    
> 
> In particular, a lua context (AFAIK) is completely single-threaded so two debugger objects would never be able to run the lua interpreter concurrently.
> 
> b) It is unnecessary, because lua is perfectly capable of creating completely independent contexts.
> 
> For these reasons, I'd like to explore the possibility of just creating distinct lua contexts for each (SB)Debugger object. I think we could drop a lot of complexity this way (the weird `session_is_active` "locking" is just the tip of the iceberg). Doing that will probably require a bit of refactoring, as right now the assumption is that each ScriptInterpreter instance is global, but I don't think that should be too hard (for python we could have a per-debugger shin, backed by a global object).
> 
> It may turn out that this is a dead-end, because the lua context will be "too independent", but I'd be sad if we didn't even try that. In particular, if this pans out and we think that's a good design, I think we could do some work to cleanup/simplify python as a result (PyInterpreterState_New <https://docs.python.org/3/c-api/init.html#c.PyInterpreterState_New> and friends).

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71801/new/

https://reviews.llvm.org/D71801