[lldb-dev] [RFC] Supporting Lua Scripting in LLDB

Mon Dec 9 09:27:14 PST 2019

On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath <pavel at labath.sk> wrote:
>
> I think this would be a very interesting project, and would allow us to
> flesh out the details of the script interpreter interface.
>
> A lot of the complexity in our python code comes from the fact that
> python can be (a) embedded into lldb and (b) lldb can be embedded into
> python. It's been a while since I worked with lua, but from what I
> remember, lua was designed to make (a) easy., and I don't think (b) was
> ever a major goal (though it can always be done ways, of course)..
>
> Were you intending to implement both of these directions or just one of
> them ((a), I guess)?

Thanks for pointing this out. Indeed, my goal is only to support (a)
for exactly the reasons you brought up.

> The reason I am asking this is because doing only (a) will definitely
> make lua support simpler than python, but it will also mean it won't be
> a "python-lite".
>
> Both of these options are fine -- I just want to understand where you're
> going with this. It also has some impact on the testing strategy, as our
> existing python tests are largely using mode (b).

That's part of my motivation for *not* doing (b). I really don't want
to create/maintain another (Lua driven) test suite.

> Another question I'm interested in is how deeply will this
> multi-interpreter thing go? Will it be a build time option, will it be
> selectable at runtime, but we'll have only one script interpreter per
> SBDebugger, or will we be able to freely mix'n'match scripting languages?

There is one script interpreter per debugger. As far as I can tell
from the code this is already enforced.

> I think the last option would be best because of data formatters
> (otherwise one would have a problem is some of his data formatters are
> written in python and others in lua), but it would also create a lot
> more of new api surface, as one would have to worry about consistency of
> the lua and python views of lldb, etc.

That's an interesting problem I didn't think of. I'm definitely not
excited about having the same data formatter implemented in both
scripting languages. Mixing scripting languages makes sense for when
your LLDB is configured to support both Python and Lua, but what do
you do for people that want only Lua? They might still want to
re-implement some data formatters they care about... Anyway, given
that we don't maintain/ship data formatters in Python ourselves, maybe
this isn't that big of an issue at all?

> On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote:
> > Hi everyone,
> >
> > Earlier this year, when I was working on the Python script
> > interpreter, I thought it would be interesting to see what it would
> > take to support other scripting languages in LLDB. Lua, being designed
> > to be embedded, quickly came to mind. The idea remained in the back of
> > my head, but I never really got around to it, until now.
> >
> > I was pleasantly surprised to see that it only took me a few hours to
> > create a basic but working prototype. It supports running single
> > commands as well as an interactive interpreter and has access to most
> > of the SB API through bindings generated by SWIG. Of course it's far
> > from complete.
> >
> > Before I invest more time in this, I'm curious to hear what the
> > community thinks about adding support for another scripting language
> > to LLDB. Do we need both Lua and Python?
> >
> > Here are some of the reasons off the top of my head as to why the
> > answer might be
> > "yes":
> >
> >  - The cost for having another scripting language is pretty small. The
> > Lua script interpreter is very simple and SWIG can reuse the existing
> > interfaces to generate the bindings.
> >  - LLDB is designed to support multiple script interpreters, but in
> > reality we only have one. Actually exercising this property ensures
> > that we don't unintentionally break that design assumptions.
> >  - The Python script interpreter is complex. It's hard to figure out
> > what's really needed to support another language. The Lua script
> > interpreter on the other hand is pretty straightforward. Common code
> > can be shared by both.
> >  - Currently Python support is disabled for some targets, like Android
> > and iOS. Lua could enable scripting for these environments where
> > having all of Python is overkill or undesirable.
> >
> > Reasons why the answer might be "no":
> >
> >  - Are our users going to use this?
> >  - Supporting Python is an ongoing pain. Do we really want to risk
> > burdening ourselves with another scripting language?
> >  - The Python API is very well tested. We'd need to add test for the
> > Lua bindings as well. It's unlikely this will match the coverage of
> > Python, and probably even undesirable, because what's the point of
> > testing the same thing twice. Also, do we want to risk fragmenting
> > tests across two scripting languages?
> >
> > There's probably a bunch more stuff that I didn't even think of. :-)
> >
> > Personally I lean towards "yes" because I feel the benefits outweigh
> > the costs, but of course that remains to be seen. Please let me know
> > what you think!
> >
> > If you're curious about what this looks like, you can find the patches
> > on my fork on GitHub:
> > https://github.com/JDevlieghere/llvm-project/tree/lua
> >
> > Cheers,
> > Jonas
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
> On 09/12/2019 09:33, Raphael “Teemperor” Isemann via lldb-dev wrote:
> > I think this is great, thanks for working on this! My only concern
> > is that I would prefer if we could limit the Lua tests to just the
> > Lua->C++ calling machinery (e.g., that we handle Lua strings
> > correctly and all that jazz) and not fragment our test suit.
> > Otherwise Lua seems to require far less maintenance work than
> > Python, so I am not worried about the technical debt this adds.
> I agree -- I think our position should be (at least until lua support is
> very mature) is that the primary api testing language should be python.
> I.e., every new api should have a python test, and a lua test can be
> added when there is something interesting lua-specific going on.
>
> pl