[lldb-dev] Anybody using the Go/Java debugger plugins?

Tue Jan 30 05:30:12 PST 2018

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

On Tue, Jan 30, 2018 at 11:52 AM Pavel Labath via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> 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
>
> On 22 January 2018 at 20:13, Jim Ingham <jingham at apple.com> wrote:
> > 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
> >
> >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >>
> >> 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.
> >>
> >>
> >> On 22 January 2018 at 15:28, Davide Italiano <dccitaliano at gmail.com>
> wrote:
> >>> 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?
> >>>
> >>> --
> >>> Davide
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180130/8b647d3c/attachment.html>