[lldb-dev] lldb access in Emacs via realgud

[Greg Clayton via lldb-dev]

> On Sep 12, 2019, at 7:33 PM, Adrian Prantl <aprantl at apple.com> wrote:
> 
> 
> 
>> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein <rb at dustyfeet.com <mailto:rb at dustyfeet.com>> wrote:
>> 
>> 
>> 
>> On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>> 
>> 
>> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein <rb at dustyfeet.com <mailto:rb at dustyfeet.com>> wrote:
>> > 
>> > 
>> > 
>> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>> >> 
>> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190913/c686d727/attachment.html>