Emacs 写 C 项目步骤

gcc 编译器。

gdb 调试器。

Emacs 写 C 项目的步骤

命令 / 工具	实质	解决的痛点
sudo apt install build-essential	安装基础 C/C++ 构建工具集合，包含 GCC、Make 等	Emacs 本身不负责把 C 源码编译成程序
sudo apt install gdb	安装 GDB 调试器	Emacs 本身没有 C 程序的底层调试能力
M-x compile	在当前 buffer 的 default-directory 中启动一个异步编译命令	不必离开 Emacs 去终端编译；编译结果还能被 Emacs 解析
gcc -std=c17 -Wall -Wextra -Wpedantic -g -O0 main.c -o hello	一条具体的 GCC 编译命令	明确使用什么标准、警告、调试信息和输出文件
M-x project-shell	在项目根目录启动 Shell	不管当前文件藏在 src/ 多深，都能直接从项目根运行 ./hello、make 等
M-x shell	在当前 buffer 的 default-directory 启动 Shell	在 Emacs 内直接使用普通 Shell
M-x project-compile	在项目根目录启动 Compilation	避免当前文件位于 src/ 时，从错误目录执行 make
M-x recompile	重复最近一次 Compilation 命令	避免反复输入 make -k、GCC 参数等
Makefile	描述构建目标、依赖关系和构建规则	不再手写长串 GCC 命令；项目只重新编译必要部分，并让构建方法可重复
M-x gdb	启动 GDB 调试器，并进入 Emacs 的图形化 GDB 界面	在 Emacs 中调试已经编译出来的程序
M-x gud-break	【源码 buffer】在当前代码行设置断点	让程序运行到指定位置时暂停，方便观察当时的变量、调用栈和状态
点击 fringe 红点	【GDB 管理的源码 buffer】图形化设置/删除 breakpoint	和 gud-break 本质一样，只是鼠标操作更直观
M-g n（next-error）	跳到下一条已解析的错误/警告对应源码位置	不必看着 main.c:37:5 再手工寻找第 37 行
M-x gud-next	【源码 buffer】执行下一行，但不进入被调用函数	想逐行观察流程，但暂时不关心函数内部
M-x gud-step	【源码 buffer】执行下一步，并进入被调用函数	怀疑某个函数内部出了问题，需要钻进去看
M-x gud-cont	【源码 buffer】继续运行，直到下一个断点/异常	不需要一行一行走完整个程序
M-x gud-finish	【源码 buffer】运行到当前函数返回	已经确认这个函数没问题，快速退出它
M-x gud-up	【源码/GDB 调试上下文】切换到调用栈的上一层 stack frame	查看“是谁调用了当前函数”，以及调用者当时的变量
(gdb) print numerator	【GDB buffer】计算并显示一个表达式当前的值	查看程序暂停这一刻变量到底是什么
(gdb) backtrace / bt	【GDB buffer】显示整个调用栈	搞清楚程序是沿着哪条函数调用路径走到当前位置的

                写 C

                  │

              main.c

                  │

          GCC / Make

        【负责构建】

                  │

                hello

             可执行程序

                  │

          ┌───────┴────────┐

          ↓                ↓

       直接运行            GDB

      ./hello           【负责调试】

                           │

                   breakpoint

                   next / step

                   print / bt

Emacs 把这一切包起来：

源码 buffer

    ↕

Compilation buffer

    ↕

Shell buffer

    ↕

GDB buffer