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

[Pavel Labath via lldb-dev]

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
>