[RFC] Removing lldb-mi

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the repository. It is basically unmaintained, doesn’t match the LLDB code style, and worst of all the tests are unreliable if not already disabled. As far as I can tell it’s missing core functionality to be usable from something like say emacs.

Thanks,
Jonas

We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really like to keep it! :blush:

Ted

Is there any reason why this can’t be a downstream project?

Thanks,

I am in favour of this proposal, for all of the reasons stated above. Since lldb-mi uses lldb stable API, any interested parties can easily create a separate project for it on github (or wherever). Maybe this would even serve as a spark to reignite lldb-mi development (which has been sitting in idle for quite some time now).

pl

I use a plugin in Visual Studio Code , that uses lldb-mi. It works fairly well for me. Ciao Nat!

We’re using it with Eclipse and Eclipse based product, so I’d like to keep as well! :-)…

Zdenek

I do understand that there’s desire from people to keep this around (from an user perspective), but I guess this fundamentally misses Jonas’ original mail point.
lldb-mi has been unmaintained for a long time (at least the past two years from what I can tell), and we tried to use it in emacs without success.
It has never been a priority for many of the parties putting effort in lldb and I’m under the impression the situation won’t change in the foreseeable future.
Unless somebody steps up as maintainer I don’t think there’s a lot of future for the tool.
Maybe a good compromise would be that of having lldb-mi living in a separate repo somewhere on GitHub, as it only uses the SBAPI, which is public and set in stone?

I just went forward with this and made a quick test repo with an out-of-tree lldb-mi that compiles against the system LLDB: https://github.com/Teemperor/lldb-mi This seems to work fine with the exception of the python tests which require LLDB’s python code for testing which isn’t installed alongside LLDB. I guess we will have to see if we copy the related test code there or we just rewrite the test suite (which is anyway broken). On the upside, we can now just use Travis for CI as we don’t have to compile LLVM/Clang/LLDB, so that’s nice.

I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give downstream time until 10.0.0 (or X.0.0 :slight_smile: ) to package out-of-tree lldb-mi for users. Given how simple lldb-mi is, this seems like a reasonable timeframe.

  • Raphael

Thank you for doing this, Raphael. I believe this shows that it’s possible to keep lldb-mi alive, without today’s maintenance burden on the LLDB community, a solution that seems to appease everyones concerns in this thread. I hope this sparks interest for somebody to step up as a maintainer.

I went ahead and created a diff to add the proposed deprecations to the LLVM release notes: https://reviews.llvm.org/D64254
I’ll put up another diff to remove the code, which we can land once LLVM 9 has branched.

Thank you,
Jonas

As of yesterday, lldb-mi has been removed from lldb and moved to https://github.com/lldb-tools/lldb-mi .

Some questions:

  • Is the expected way to build lldb-mi to drop the lldb-tools/lldb-mi repo into /tools/lldb-mi?
  • The lldb-mi tests weren’t moved into the new repo on github. Do we plan on moving them?
  • If we don’t move them, do we just rely on the lldb-mi executable not existing to keep from trying to run them?
  • If we do move them, how do we run them?

Ted

The expected way as of now is to compile lldb-mi against an installed lldb (either a compiled version or whatever your OS/package manager provides). The CMake file will automatically find LLDB and build against it. See the travis CI script[1] in the repo on how that looks in practice.

The problem with the tests is that:

1. They (randomly) fail, which is why we already disabled most (all?) of them even before we removed lldb-mi. That’s mostly because of lldb-mi bugs and the way the tests were implemented from what I understand.
2. They depend on the LLDB python testing logic which isn’t as trivial to port over to the standalone lldb-mi repo. And the testing logic also not distributed with LLDB.

So after some discussion we decided that we don’t port the tests over as it’s just not worth it. The ideal outcome would be that someone writes a new set of tests that are is stable than the ones we had.

- Raphael

[1] https://github.com/lldb-tools/lldb-mi/blob/master/ci/travis.sh