Anybody using the Go/Java debugger plugins?

Hi,
during my wandering I stumbled upon the `Go` and the `Java` plugins in
the lldb source tree.
They seem to not have been touched in a while, and I'm not necessarily
sure they're in a working state. Keeping them in tree is a maintenance
burden, so unless somebody is actively using them or somebody is
willing to step up as maintainers, I'm not necessarily sure we should
pay this price.

An alternative would be that of having a pluggable mechanism to add
language support (I haven't fleshed out the details of this yet, but
it should be possible, somehow). Other languages which have out of
tree support might benefit from this (e.g. Swift/Rust).

Thoughts?

The Go support for added by Ryan as a 20% project. Now that he's no
longer working for Google, it's pretty much abandoned.
The Java support was added by us (android folks) to support java
debugging (to a certain extent). However, we never really finished the
project, so we're not using that code now. We're hoping to come back
to it one day, but I agree we should not burden everyone else while we
make up our mind on that.

So I don't think anybody would shout at us if we removed them right
now, but maybe we should make some effort to find a maintainer for
them before removal? E.g. publicly declare that they are going to be
deleted on date <X> unless a maintainer steps up to take care of them
(we can define the minimum level of support we'd expect from such a
maintainer). Then I can e.g. forward the email to the Google Go folks
and see if anyone of them wants to take that up.

As for Java, I'm going to bring up the desire to remove the Java
plugin on our team's meeting this week and get back to you with the
result.

In general I think that a clear deprecation/removal process would be
nice to have. I have a couple of things I think are broken/unused
(PlatformKalimba? non-stop mode?) but I haven't brought them up
because I was unsure how to handle it.

To Davide's alternative: LLDB does handle loading plugins that use the SB API's (for things like data formatters.) But there's not currently an SB interface to support
writing a full language plugin, and we don't export the lldb_private API's from the lldb binary. So there's no current mechanism to provide out-of-tree language plugins. It would be great to enable out-of-tree language support mechanisms but we would have to design an SB interface for that purpose.

I see occasional questions about using Go with lldb on stack overflow and the like. It might be good to put out a more general "anybody interested in supporting this" call for Go, but I'm not sure the lldb-dev list is the best place to find an owner. Is there some Go dev list we can ask to see if anybody cares to support this?

Non-stop never actually worked, it was just a promise, and the code for it was pretty thin. I would be okay with pulling that out unless somebody is actually getting good use out of it.

Jim

Right, so, independently of this thread here, we've had an internal
discussion about reviving java support. However, it is still very
uncertain that this will actually happen , so I'm not opposed to
removing it as we can always add it back later (with better testing,
hopefully).

Regardless of what happens here (and in light of the rust thread), I
think a clearer bar for what we expect from new language support
plugin would be useful for everyone.

pl

Originally I added the Java support to work with the Android ART runtime and it has some pretty hard beaked in dependencies on the debug info ART generates and on the version of ART available at that time (Android N) even though I don’t think this limitation is communicated clearly in source code or in code reviews. Considering that AFAIK it haven’t been tested with Android O and haven’t seen any bugfix for a while I would assume it is mostly unused so I am happy to get it removed. And as Pavel said if somebody want to use it again we can always add it back in with a better testing strategy and long term plan.

Generally for new language support I think we should have a similar policy then what LLVM have for new backends. They should be developed out of tree first without us providing a stable API (developer can fork a specific version of LLDB, preferably upstream language independent bugfixes and then pull in new changes once in a while) and if they are mature enough both in terms of testing and maintenance commitment then they can be pulled into the main LLDB source tree.

Tamas

I agree.
I plan to remove the two backends (well, at least submit requests for)
in 3 weeks from today.
There are a lot of moving pieces right now and I'd really love for
things to stabilize but also give people an opportunity to speak up,
if they want to.

I agree.

Just to check: Does that apply to Tamas's paragraph below, as in
that's the guidelines we should be giving to new language plugin
implementors?

If that's the case, then I agree as well, although I think we should
be a bit more clean on the details (e.g. does a test that runs only if
the developer has a specific version of the language X's compiler
installed count?)

I plan to remove the two backends (well, at least submit requests for)
in 3 weeks from today.

BTW, what made you skip OCaml? :stuck_out_tongue:

I agree.

Just to check: Does that apply to Tamas's paragraph below, as in
that's the guidelines we should be giving to new language plugin
implementors?

Yes, that's what I meant.

If that's the case, then I agree as well, although I think we should
be a bit more clean on the details (e.g. does a test that runs only if
the developer has a specific version of the language X's compiler
installed count?)

I plan to remove the two backends (well, at least submit requests for)
in 3 weeks from today.

BTW, what made you skip OCaml? :stuck_out_tongue:

Nothing, I just didn't notice we had support for it :slight_smile: