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 <tbergham...@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@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 <jing...@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@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 <dccitali...@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@lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
