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
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
- 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: