Emacs LLDB support & the GDB/MI Interface

Developers here may or may not be aware that there’s some serious interest from Emacs users to have proper support for LLDB in Emacs.

There’s been some pretty heated debate that included RMS, but the community has pretty much told him what they think about his opinion and are willing to accept any solid effort at adding support.

The issue has been brought up again here:
https://www.reddit.com/r/emacs/comments/6qbwjl/seriously_how_can_i_use_lldb_in_emacs/

And one thread seems to indicate that if if we could “convince LLDB developers to provide a decent implementation of the GDB/MI protocol, then using LLDB from Emacs will be a no-brainer, and probably won’t require any sanction from any Emacs developer.”

Can we get some love from the LLDB dev community to get this moving in the right direction?

Unfortunately there are plenty of us macOS developers who use Emacs and really just can’t function well without LLDB support.

That is an oxymoron.

MI protocol was designed to minimize the amount of data transferred between
gdb/lldb and a front end. But this communication isn't anything expensive as
the debugger always runs on the same host as the frontend anyway
(gdb/lldb<->gdbserver link is for remote debugging). Unfortunately complexity
of the GDB/MI protocol from this misoptimization leads to many bugs on both
sides of the implementation, for GDB:
  Bug List
  101 bugs found.

The MI protocol in use does not conform to its spec as there is a bug-to-bug
compatibility instead such as:
  Tom Tromey - Re: [patch] MI: breakpoint "script" is a LIST

There still also isn't any reasonable MI library to be used by a front end.

I find the LLDB API to be a better choice to be used by the frontend/emacs
(I have only little but great experience with the LLDB API).

Jan

Date: Sat, 29 Jul 2017 22:43:59 +0200
Cc: lldb-dev@lists.llvm.org
From: Jan Kratochvil via lldb-dev <lldb-dev@lists.llvm.org>

MI protocol was designed to minimize the amount of data transferred between
gdb/lldb and a front end. But this communication isn't anything expensive as
the debugger always runs on the same host as the frontend anyway
(gdb/lldb<->gdbserver link is for remote debugging). Unfortunately complexity
of the GDB/MI protocol from this misoptimization leads to many bugs on both
sides of the implementation, for GDB:
  Bug List
  101 bugs found.

The MI protocol in use does not conform to its spec as there is a bug-to-bug
compatibility instead such as:
  Tom Tromey - Re: [patch] MI: breakpoint "script" is a LIST

There still also isn't any reasonable MI library to be used by a front end.

Correct or not, buggy or not, the Emacs support for GDB is based on
MI, and it works reasonably well for the last few years. So much so
that Emacs developers have deprecated the previous GUD interface based
on annotations (which are also deprecated by the GDB team).

I find the LLDB API to be a better choice to be used by the frontend/emacs
(I have only little but great experience with the LLDB API).

Good luck with that attitude having LLDB support in Emacs any time
soon. Even supporting it via the ancient GUD, which required a couple
of minor changes, was met with some resistance. (Some think that this
resistance was overcome, but IMO the jury is still out on that one,
and we won't know the truth until an attempt to add that support is
made in earnest.)

Having LLDB support MI would solve this problem cleanly and
seamlessly. It's your call to decide whether Emacs support is
important enough to you to do that.

Are we talking about some kind of mi support other than lldb’s existing MI interface? Afaik it works reasonably well (for some definition of reasonably well), and is even used for example in msvc on windows to support remote debugging of non windows targets.

That said, most lldb developers are paid by their company to work on specific things that are important to their company’s users, and emacs support is probably not going to be that high up on the list.

So if you can figure out where the deficiencies are in the existing mi implementation, patches are always welcome

Last time I tried, it wasn't "reasonable" enough to start debugging a
program under Emacs. See this discussion for details:

http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html

The failed commands it shows are the initial ones issued by Emacs
when a debugging session starts. Without support of these commands in lldb-mi there's no hope for any
practical debugging using lldb.
If llvm developers could implement those minimal commands, maybe the
rest would be easier.

Sorry, I meant http://lists.llvm.org/pipermail/lldb-dev/2016-December/108511.html

It's embarrassing... The correct URL is http://lists.llvm.org/pipermail/llvm-dev/2016-December/108511.html

Last time I tried, it wasn't "reasonable" enough to start debugging

a

program under Emacs. See this discussion for details:

http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html

The failed commands it shows are the initial ones issued by Emacs
when a debugging session starts. Without support of these commands

in

lldb-mi there's no hope for any
practical debugging using lldb.
If llvm developers could implement those minimal commands, maybe the
rest would be easier.

I will try to add those command when my time allows. If there are others
that are needed to make Emacs work then please let me know or better
open a bug.

Thanks,
Abid

The original lldb-mi implementation was to get Eclipse talking to lldb. Since then there have been other people working on it, and other clients, but lldb-mi is not a full implementation of the MI protocol.

The best thing to do is give us a list of commands that are failing, in a bug opened in Bugzilla at http://bugs.llvm.org .

Ted

From: "Ted Woodward" <ted.woodward@codeaurora.org>
Cc: <ylluminate@gmail.com>
Date: Mon, 31 Jul 2017 13:24:31 -0500

The best thing to do is give us a list of commands that are failing, in a bug opened in Bugzilla at http://bugs.llvm.org .

The URL I provided (after several mistaken attempts :wink: included a
lits of the failing commands.

You are probably got it but yes, -file-list-exec-source-files and -break-list commands are not implemented yet. I’ll try to find the time to fix it.

From: Ilia K <ki.stfu@gmail.com>
Date: Sun, 6 Aug 2017 13:20:13 +0300
Cc: Ted Woodward <ted.woodward@codeaurora.org>, ylluminate@gmail.com,
  jan.kratochvil@redhat.com, LLDB <lldb-dev@lists.llvm.org>

You are probably got it but yes, -file-list-exec-source-files and -break-list commands are not implemented yet.
I'll try to find the time to fix it.

Thanks.