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

Mon Dec 9 17:01:01 PST 2019

Given that the response so far has been positive, I've put up the
patches for review:

https://reviews.llvm.org/D71232
https://reviews.llvm.org/D71234
https://reviews.llvm.org/D71235

Jonas

On Mon, Dec 9, 2019 at 9:27 AM Jonas Devlieghere <jonas at devlieghere.com> wrote:
>
> 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