[lldb-dev] Anybody using the Go/Java debugger plugins?
Jim Ingham via lldb-dev
lldb-dev at lists.llvm.org
Mon Jan 22 12:13:31 PST 2018
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.
> 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
> 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:
>> 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).
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the lldb-dev