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

[Davide Italiano via lldb-dev]

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.

--
Davide

On Tue, Jan 30, 2018 at 5:30 AM, Tamas Berghammer
<tberghammer at google.com> wrote:
> 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