This is an archive of the discontinued LLVM Phabricator instance.

[lldb/Lua] Generate Lua Bindings and Make Them Available to the Script Interpreter
ClosedPublic

Authored by JDevlieghere on Dec 9 2019, 4:58 PM.

Details

Reviewers
labath
Group Reviewers
Restricted Project
Commits
rGbf03e17c5701: [Lldb/Lua] Generate Lua Bindings
Summary

This patch uses SWIG to generate the Lua bindings for the SB API. It covers most of the API, but some methods require a type map similar to Python.

Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html

Diff Detail

Event Timeline

JDevlieghere created this revision.Dec 9 2019, 4:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2019, 4:58 PM
Herald added subscribers: abidh, mgorny. · View Herald Transcript
xiaobai added a subscriber: xiaobai.Dec 9 2019, 5:11 PM
JDevlieghere retitled this revision from [Lldb/Lua] Generate Lua Bindings and Make Them Available to the Script Interpreter to [lldb/Lua] Generate Lua Bindings and Make Them Available to the Script Interpreter.Dec 9 2019, 5:47 PM
labath added a subscriber: labath.Dec 10 2019, 2:41 AM
labath added inline comments.
lldb/scripts/CMakeLists.txt
42–64

This looks like it could/should be shared between lua and python.

lldb/scripts/lldb_lua.swig
11–171

Can we figure out a way to share this stuff? I guess it could be just put into a common header and %included from the language-specific files..

174

This shouldn't be needed if lua is only ever used from within lldb (mode a).

lldb/source/Plugins/ScriptInterpreter/Lua/CMakeLists.txt
6

I'd like to discuss this bit in more detail, as you've chosen to do things differently than python. While it does seem strange to have python (&lua) code built in the API folder, there is a reason for it -- this stuff depends on the lldb public api. Having it here creates a loop between the API folder and this script interpreter. One of the effects of that will be that it will be impossible to create a unit test binary for testing the lower level lua code (which I think it would be useful, just as equivalent python unit tests are shown themselves to be useful).

Unfortunately, moving this stuff to the API folder does not completely remove the cycle (though it makes it much easier to work around it), because there will still be some API code which you'll need to call from within the script interpreter. Right now, that's just the luaopen_lldb but there will be others in the future.

I'd like to take this opportunity to create a solid story for the separation of responsibilities and layering between these two entities. If we can figure out a good solution here, then the we could also retrofit python to follow the same pattern. They way I would define "good layering" is that if "A is implemented on top of B" then it should be possible to define the purpose of "B" as well as implement it without referencing any concepts which are only defined in "A".

The way I would try to define the relationship of lua/python script interpreters and the API code is that the script interpreter operates on the lower level lldb_private debugger objects -- i.e., it sits "on top of" pretty much everything else *except* the API folder. It implements all of the interesting stuff about interacting with python/lua *except* how to actually represent the lldb_private entities in python. This last bit a customization point, which needs to be provided by the thing which it uses it -- in our case the API folder. This could be done by having funtcions which take the lldb_private objects, wrap them in the appropriate lldb object, and then wrap *that* via swig. And unwrapping could proceed similarly. This way, the python/lua code would never see any lldb::SB*** classes -- it would just see lldb_private classes, and their fully lua wrapped versions.

And the API folder would be left with the job of wrapping lldb_private objects into lua form and back, which isn't totally unreasonable -- the main job of the API folder is to provide a stable interface to lldb, and that is something we want to have in lua too. It does mean that there will have to be some language specific code in API folder, but I currently don't see a way to avoid that (though I'd like to see someone try to do that).

emaste added a subscriber: emaste.Dec 16 2019, 12:51 PM
JDevlieghere marked an inline comment as done.
  • Rebase
  • Move wrapper to API
  • Add test case

Very cool BTW!

labath accepted this revision.Dec 21 2019, 2:17 AM

This looks fine. Things will start to get interesting once you start wanting to access the current session from inside the lua script (not just creating a new one),,

This revision is now accepted and ready to land.Dec 21 2019, 2:17 AM
This revision was automatically updated to reflect the committed changes.
mstorsjo added inline comments.
lldb/CMakeLists.txt
55

This change here (unconditionally including the scripts subdir) made SWIG a hard dependency, even if both lua and python are disabled.

I pushed a commit to fix that, I hope that's ok.

JDevlieghere marked an inline comment as done.Dec 22 2019, 10:56 AM
JDevlieghere added inline comments.
lldb/CMakeLists.txt
55

Totally, thanks for fixing this!