> On Sep 12, 2019, at 7:33 PM, Adrian Prantl <apra...@apple.com> wrote: > > > >> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein <r...@dustyfeet.com >> <mailto:r...@dustyfeet.com>> wrote: >> >> >> >> On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl <apra...@apple.com >> <mailto:apra...@apple.com>> wrote: >> >> >> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein <r...@dustyfeet.com >> > <mailto:r...@dustyfeet.com>> wrote: >> > >> > >> > >> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl <apra...@apple.com >> > <mailto:apra...@apple.com>> wrote: >> >> >> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev >> >> > <lldb-dev@lists.llvm.org <mailto: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 >> >> > <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 >> >> >> >> <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 >> > <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 >> <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? > <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?
Yes, we indeed to implement the VS Code debug adaptor protocol. This isn't MI, but a different JSON based transport layer that is quite similar to the level the GDB MI comes in at. I am happy to answer any questions on the debug adaptor protocol if needed. The communication can happen via stdin/out or via a port TCP.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
