背景介绍：

libgdb过时了，目前的GDB调试前端都不用libgdb

目前有两种比较流行：

- MI接口，现在应该是MI II接口，是Eclipse CDT所采用的方式

- emac输出接口，这个似乎有更多的调试前端所采用，例如DDD，kdbg，codeblocks等等

另外还有一种比较另类的一种方式：insight，直接把gdb给包含进去了

MI不但包括了CLI的所有命令，还具备一些CLI所不提供的功能，也就是说MI的命令一般与gdb的命令有一个映射的关系。当然，MI接口的设计初衷是面向将 GDB作为系统组件之一的复杂系统。在类似于DDD，Insight等以GDB为后端（backend）的GUI debugger的实现中，就是充分利用了GDB MI接口。MI最大的不足在于其输出的文本流接口比较复杂，必须很熟悉其输出格式才能理解，不如CLI输出直观。

 

简单地说，GDB MI interpreter 接受字符串形式的命令输入，然后产生一行表示命令执行结果的输出。当然，这里的输入命令和输出记录都有严格的格式和内容定义。而且，根据命令的不同（同步 命令或异步命令），GDB的输出也代表不同的含义。当利用GDB MI实现一个GUI的debugger时，通常的做法是使用一个进程负责管理GDB，将GDB作为其子进程派生出来后，接管其标准I/O，并通过pipe 向GDB注入MI命令，并接收GDB MI输出。自然，该进程的另一个工作就是与GUI前端交互，完成GUI命令解析以及返回相应record. Simple？:-)

 

Insight使用Tcl/tk实现前端GUI，DDD使用的则是Gtk。前段时间正好学习了Python，是不是可以用Python+GDB MI来作一个GUI Debugger？正好还可以复习一下前一阵子看过的程序link and load 过程。

 

注：GDB MI的详细介绍参见GDB 手册： Debugging with GDB.其中专门一章讨论MI接口。

 

 

MI（翻译为Machine Interface）。因为最近在用Eclipse的CDT调试C/C++，当然Eclipse本质gdb的调用，对于gdb的命令很多人可能都已经很熟悉了，本文介绍的mi层命令可能很少有人用到，它也是gdb的一部分，主要目的是为一些目标系统如IDE等提供调试功能，如eclipse下c/c++的cdt插件的底层就是调用的mi层命令，cdt的包里面有两个类RxThread,TxThread就是一个发送mi命令，一个接收返回数据的，大家有兴趣可以研究下。

 

进入命令 gdb --interpreter mi [exec_file]

退出命令 quit

 

mi的命令总共分为以下几个部分：

1.断点(Breakpoint)

2.程序环境(Program Context)

3.线程(Thread)

4.程序执行(Program Execution)

5.栈(Stack)

6.变量(Variable)

7.数据(Data)

8.跟踪点(Tracepoint)

9.符号(Symbol)

10.文件(File)

11.目标数据(Target Manipulation)

12.其它杂项

 

像我们在Eclipse 的console上见到的-var-evaluate-expression，-stack-list-locals，-exec-continue 诸如此类的都是mi的命令。

 

references：

http://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_211.html#SEC216

http://jlspyaozhongkai.blog.163.com/blog/static/116057464200995103415205/

http://blog.csdn.net/coutcin/article/details/1074330   （一些mi命令详解可以参考这里）

http://www.ibm.com/developerworks/cn/opensource/os-eclipse-cdt-debug1/

http://www.ibm.com/developerworks/cn/opensource/os-eclipse-cdt-debug2/