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.<br><br>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.<br><br>So if you can figure out where the deficiencies are in the existing mi implementation, patches are always welcome <br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 29, 2017 at 7:39 PM Eli Zaretskii via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Date: Sat, 29 Jul 2017 22:43:59 +0200<br>
> Cc: <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> From: Jan Kratochvil via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>><br>
><br>
> MI protocol was designed to minimize the amount of data transferred between<br>
> gdb/lldb and a front end.  But this communication isn't anything expensive as<br>
> the debugger always runs on the same host as the frontend anyway<br>
> (gdb/lldb<->gdbserver link is for remote debugging).  Unfortunately complexity<br>
> of the GDB/MI protocol from this misoptimization leads to many bugs on both<br>
> sides of the implementation, for GDB:<br>
>       <a href="https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced" rel="noreferrer" target="_blank">https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced</a><br>
>       101 bugs found.<br>
><br>
> The MI protocol in use does not conform to its spec as there is a bug-to-bug<br>
> compatibility instead such as:<br>
>       <a href="https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html</a><br>
><br>
> There still also isn't any reasonable MI library to be used by a front end.<br>
<br>
Correct or not, buggy or not, the Emacs support for GDB is based on<br>
MI, and it works reasonably well for the last few years.  So much so<br>
that Emacs developers have deprecated the previous GUD interface based<br>
on annotations (which are also deprecated by the GDB team).<br>
<br>
> I find the LLDB API to be a better choice to be used by the frontend/emacs<br>
> (I have only little but great experience with the LLDB API).<br>
<br>
Good luck with that attitude having LLDB support in Emacs any time<br>
soon.  Even supporting it via the ancient GUD, which required a couple<br>
of minor changes, was met with some resistance.  (Some think that this<br>
resistance was overcome, but IMO the jury is still out on that one,<br>
and we won't know the truth until an attempt to add that support is<br>
made in earnest.)<br>
<br>
Having LLDB support MI would solve this problem cleanly and<br>
seamlessly.  It's your call to decide whether Emacs support is<br>
important enough to you to do that.<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>