Alternative bindings for the SB* API

Hello all,

I have partial JavaScript bindings for the SB* API. I’ve generated them via SWIG and when using a current version of SWIG (3.03 or later, I think), they generate something that can work for Node.JS, io.js and other environments. I’ve just been using these for some proof of concept work, so they aren’t complete yet.

It is probably possible to work on upstreaming these changes into LLDB. It requires moving the *.i files into a directory where they aren’t entirely specific to Python.

This does bring up the point that if that were to happen, it would be a good time to more clearly mark what is good practice in the SB* API and what shouldn’t be wrapped in new bindings. (There’s no old code for JS or other languages to worry about breaking, so they can ignore deprecated APIs.)

The above path is kind of tricky and annoying at times though, so I’ve thought about manually writing a C wrapper around the C++ SB* API and using that for bindings instead. This would be more readily accessible in more languages (that often interoperate with C better than they do C++).

Is there interest in generalizing the SWIG bindings generation and including other languages than Python?

Is there interest in a C wrapper for the SB* API?

Is there a preference as to which approach might be more welcome? Lately, I’ve been leaning towards the C wrapper being more useful to me across a couple of projects, including one where I’d be writing code using the LLDB API in Dylan (http://opendylan.org/) where we have an excellent C FFI but not a C++ FFI.

  • Bruce

I would be very happy to see support for additional languages. Lua in
particular may interesting for LLDB in the FreeBSD base system at some
point in the future. I'm not sure if anyone else would have interest
in Lua, but at least adding it as a third language should be easier
than adding the second.

Maybe we can add support for Python3 too. I know that moving off of Python 2 is a non-starter because of legacy code, but if it’s ever going to happen in the future, then starting earlier is better than starting later, and this would be a good starting point.

For what it’s worth, the python-based swig generation script has support for other languages. There’s a top level script which recurses into each language-specific subdirectory and runs a script in that directory to shell out to swig for the final creation. So that part should be extensible.

That's what I do for my JS bindings already, although I am still using the
old shell script code in that tree. I did have to move the *.i files though
and modify them to only conditionally include some stuff that is Python
specific.

But the SWIG approach is rather painful for some other languages, so I'd
like to hear if others might want a more straight forward (in terms of
bindings) C API.

- Bruce

What languages are they painful for? (Just curious).

Assuming this gets upstreamed, which probably needs more consensus although I personally support it, it seems like that would be a good time to kill off the shell scripts. There’s no sense maintaining two sets of scripts to generate the bindings, and unfortunately we cannot rely on a bash or any other kind of shell environment on windows. So it makes sense to do all new development in the python scripts. Until now we’ve been updating both sets as necessary, but if we’re going to contribute something substantial, it would be a good time to kill the shell scripts and do everything in Python.

The only that doesn’t yet use the Python scripts is the Xcode build. It shouldn’t be hard to tweak a line somewhere and have it switch over to the python stuff, just nobody’s done it yet.

One good thing about the SWIG approach is that it is easy to introduce all the niceties that make LLDB a good fit for the language that is wrapping it (like property accessors, iterators, object printing and the like.

Anyway, we designed LLDB so it could - in theory - be extended to support whatever languages SWIG supported. If you are going to do this job right, you would also need to extend the script interpreter from its current 1 language to many, and add ability to do breakpoint commands, etc, in the various languages.

I'm on the fence about what to do with the .i files if we're going to start supporting other extension languages. They will get awfully cluttered if we actually start using them as intended for Python extras AND JS extras, AND... Maybe we will want to split out the "just copied over from the .h file" portion of the .i files, and then have multiple language support versions?

Making C bindings so you can then turn around and wrap them in some other language seems a rather low-fidelity way of doing the same job. How do you then put back together all the classes you've taken apart to make a coherent API? I'm afraid you'd just get slowly dragged into reproducing the work that SWIG did. If somebody wants to do that, then it would be better to do something clever using say that nice C++ front-end we have lying around and generate bindings that way.

Jim

jingham@apple.com schreef op 2/18/2015 om 2:56 AM:

One good thing about the SWIG approach is that it is easy to
introduce all the niceties that make LLDB a good fit for the language
that is wrapping it (like property accessors, iterators, object
printing and the like.

Anyway, we designed LLDB so it could - in theory - be extended to
support whatever languages SWIG supported. If you are going to do
this job right, you would also need to extend the script interpreter
from its current 1 language to many, and add ability to do breakpoint
commands, etc, in the various languages.

I'm on the fence about what to do with the .i files if we're going to
start supporting other extension languages. They will get awfully
cluttered if we actually start using them as intended for Python
extras AND JS extras, AND... Maybe we will want to split out the
"just copied over from the .h file" portion of the .i files, and then
have multiple language support versions?

Making C bindings so you can then turn around and wrap them in some
other language seems a rather low-fidelity way of doing the same job.
How do you then put back together all the classes you've taken apart
to make a coherent API? I'm afraid you'd just get slowly dragged
into reproducing the work that SWIG did. If somebody wants to do
that, then it would be better to do something clever using say that
nice C++ front-end we have lying around and generate bindings that
way.

So SWIG actually supports multiple languages on the same binding? I currently have my own C# bindings (http://pastie.org/9963898) for SWIG because I couldn't figure out how to reuse the python ones (My idea was to look into an open source VS debugger plugin that uses lldb and gets triggered from the existing llvm platform support)