4 ms·

GDB can be driven remotely since a long time. Emacs and Eclipse both integrate GDB via the MI interface. LLDB supports it as well. https://sourceware.org/gdb/c

by jpfr 8y ago

GDB can be driven remotely since a long time. Emacs and Eclipse both integrate GDB via the MI interface. LLDB supports it as well. https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI... What is the advantage of the debug adapter protocol against the existing debugger--editor integration protocols?

int_19h 8y ago
Mainly that DAP was designed as such from the get go, with multiple implementations for many very different languages being one of the driving assumptions behind its design. MI, on the other hand, was originally just an API to use gdb programmatically, and was later repurposed by others simply because it was already implemented by other tooling, dealing with its gdb-specific idiosyncrasies being the path of least resistance. https://kichwacoders.com/2017/08/02/gdbs-mi-is-not-a-debug-protocol/ https://kichwacoders.com/2017/08/02/gdbs-mi-is-not-a-debug-p... As a consequence, DAP is much easier to work with from the IDE side, and it's easier to implement an adapter, as well. Looking at this table - even ignoring all the Microsoft-made ones - how many of the languages listed have a MI debugger implementation? https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/ https://microsoft.github.io/debug-adapter-protocol/implement... On the tooling side, Emacs and Eclipse are both covered: https://microsoft.github.io/debug-adapter-protocol/implementors/tools/ https://microsoft.github.io/debug-adapter-protocol/implement... Still, for native debugging specifically, it's a good point that on the IDE side, MI is currently better supported. So implementing that first would make more sense in terms of lighting up more IDEs, at the price of a somewhat more complex implementation. DAP can be implemented on top of MI - this is exactly what the VSCode C++ debug adapter does.

by jpfr 8y ago

int_19h 8y ago

Mainly that DAP was designed as such from the get go, with multiple implementations for many very different languages being one of the driving assumptions behind its design. MI, on the other hand, was originally just an API to use gdb programmatically, and was later repurposed by others simply because it was already implemented by other tooling, dealing with its gdb-specific idiosyncrasies being the path of least resistance. https://kichwacoders.com/2017/08/02/gdbs-mi-is-not-a-debug-protocol/ https://kichwacoders.com/2017/08/02/gdbs-mi-is-not-a-debug-p... As a consequence, DAP is much easier to work with from the IDE side, and it's easier to implement an adapter, as well. Looking at this table - even ignoring all the Microsoft-made ones - how many of the languages listed have a MI debugger implementation? https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/ https://microsoft.github.io/debug-adapter-protocol/implement... On the tooling side, Emacs and Eclipse are both covered: https://microsoft.github.io/debug-adapter-protocol/implementors/tools/ https://microsoft.github.io/debug-adapter-protocol/implement... Still, for native debugging specifically, it's a good point that on the IDE side, MI is currently better supported. So implementing that first would make more sense in terms of lighting up more IDEs, at the price of a somewhat more complex implementation. DAP can be implemented on top of MI - this is exactly what the VSCode C++ debug adapter does.