[lldb-dev] lldb access in Emacs via realgud

Thu Sep 12 19:48:07 PDT 2019

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 <aprantl at apple.com> wrote:

>
>
> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein <rb at dustyfeet.com> wrote:
>
>
>
> On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>>
>> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein <rb at dustyfeet.com> wrote:
>> >
>> >
>> >
>> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl <aprantl at apple.com>
>> wrote:
>> >>
>> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev <
>> 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
>> >> >
>> >> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190912/0fefdee4/attachment.html>