Your guess is as good as mine. The one you project link you give looks more akin to what I was looking for.
At any rate, rather than try to fix up lldb-mi, I'd put my (limited) resources into using one of these and beefing it up if it needs improvement. On Thu, Sep 12, 2019 at 10:33 PM Adrian Prantl <apra...@apple.com> wrote: > > > On Sep 12, 2019, at 4:45 PM, Rocky Bernstein <r...@dustyfeet.com> wrote: > > > > On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl <apra...@apple.com> wrote: > >> >> >> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein <r...@dustyfeet.com> wrote: >> > >> > >> > >> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl <apra...@apple.com> >> wrote: >> >> >> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> > >> >> > >> >> > Hi - I just wanted to mention that if there are emacs users there is >> an interface to lldb via realgud. See >> https://github.com/realgud/realgud-lldb >> >> > >> >> > A MELPA package and ELPA packageElpa package are available too >> >> >> >> Nice. It's always exciting to see wider adoption through better editor >> integration. Out of curiosity, how does this compare to regular gud.el? ( >> https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html >> ) >> > >> > "Regular" gud? The most recent copyright on that link is 2008. I see a >> gud.el in 26.2 and in the GNU savannah git sources, but neither mentions >> lldb. Assuming that file is really from 2008, has lldb changed since then? >> (This is a rhetorical question). But the broader question is really who is >> maintaining that file you link, clearly it is not the GNU Emacs community. >> And how easy is it to do so? I see an "arch" tag on the file, so I guess >> this in version control somewhere. But if there is a bug in this file, what >> does one do? (This is not a rhetorical question; if you know the answer, I >> am interested.) >> >> I think this file is effectively abandoned as it is neither part of the >> LLDB repository nor is it shipping with emacs in macOS any longer. >> >> > Adapted from https://github.com/realgud/realgud/blob/master/realgud.el >> > >> >> Here we make use of more modern programming practices, more numerous >> and smaller files, unit tests, and better use of Emacs primitives, e.g. >> buffer marks, buffer-local variables, structures, rings, hash tables. >> Although there is still much to be desired, this code is more scalable and >> suitable as a common base for an Emacs front-end to modern debuggers. >> >> Oh, and because global variables are largely banned, we can support >> several simultaneous debug sessions. >> >> > gdb-mi has a nicer multi-frame display, but you were linking to gud.el >> which doesn't have that as far as I know. realgud-lldb at this point >> probably knows more about lldb. But you guys can probably verify that, and >> if realgud-lldb is lacking, I'd be interested to learn what should be added. >> >> > >> > gud has always been a bit too monolithic - it contains every debugger >> (including some obsolete ones - does anyone really still use dbx, and if so >> inside Emacs?). All of this is in that one several-thousand-line file. I >> find this ironic because the principal author is wrote something about >> "Cathedral versus Bazaar" and this is clearly Cathedral style. >> > >> > It took me quite a while to be able to break realgud into several >> distinct files. In fact I had to write my own nodejs-like "require" package >> to be able to do internal or relative module linking. And then after that, >> more work was done to split off the debuggers from the core debugger module >> into separate github projects. >> >> Thanks for explaining the differences! >> >> Is realgud scraping lldb's console output like gud was or is it using the >> LLDB scripting API? If it isn't already you might want to consider using >> the scripting API since LLDB's console output is not necessarily stable, >> but the scripting API is. >> > > Yes, it scrapes console output and that is a problem. A big problem. > > I looked at the LLDB API and that seems pretty extensive and seems to > cover a lot more of what interaction from Emacs would like and is currently > missing. > > However as is in its current state, this isn't going to cut it because > Emacs uses its own Lisp, not Python. > > I have toyed with the idea of hooking into something more standard, and as > I said, there are so many to choose from. For example, the V8 debugger > protcol works over a websocket, and speaking over a websocket is something > you can expect IDEs to grok. Python LLDB's API to say Microsoft's Debug > Adaptor Protocol <https://microsoft.github.io/debug-adapter-protocol/> makes > sense, and https://github.com/vadimcn/vscode-lldb/blob/v1.3.0/MANUAL.md seems > to get pretty close to that. > > > [Adding Greg to the conversation] > > What's the relation between that project and > https://github.com/llvm/llvm-project/tree/master/lldb/tools/lldb-vscode? From > the comments it looks like this is actually implementing the Debug Adaptor > Protocol? > > -- adrian > > >> >> > >> >> > A question: what ever became of the effort to port the Emacs gdb-mi >> to lldb? >> >> >> >> We recently removed lldb-mi from the LLDB repository because nobody in >> the community was willing to maintain it. In particular the tests were so >> unreliable that most bots disabled them wholesale because they were so >> noisy. We had a GSoC student a year ago who was able to rewrite many of the >> tests in a more reliable fashion, but there were still a lot of issues >> outstanding after the project was completed. If you are interested in >> picking this up, it may be worthwhile to think about implementing lldb-mi >> 2.0 as thin python layer using the python SBAPI. Python may be a better >> choice for the kind of text-heavy glue-code that lldb-mi is. Alternatively >> it also shouldn't be hard at all to revive the existing C++ code. It's >> written in a different style than most of LLDB or LLVM (and IMO it should >> have never been accepted upstream in this form), but it shouldn't be hard >> to get building since it (thanks to the GSoC project!) is using only the >> stable public SBAPI. >> > >> > >> > The great thing about standards is that there are so many to choose >> from! >> >> It sounds like you are very much invested in realgud, but if anyone else >> is reading this and interested in taking up maintainership for lldb-mi, I >> think we'd be happy to welcome it back in tree as long as it is 100% >> reliably(!) tested and maintained. >> > > Or since we are soliciting help, I'd rather see something that goes to the > Microsoft Debug Adaptor Protocol if vscode-lldb doesn't fit that already. > It might even just be repackaging parts of that code so that it can present > itself that way. In the long term I don't see either gdb-mi and lldb-mi as > viable solution that is going to reduce effort across different IDE's like > the Microsoft Debug Adaptor Protocol could/does. > > >> -- adrian > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
