必须在嵌入式目标板上运行交叉编译的gdbserver可执行文件，常用命令为gdbserver :2345 ./my_app（监听2345端口并启动程序）或gdbserver :2345 --attach （附加到已运行进程），需确保端口未被防火墙拦截且程序具备调试符号。
怎么在嵌入式目标板上启动 gdbserver
必须让目标板运行 gdbserver，它才是远程调试的“服务端”。交叉编译好的 gdbserver（不是主机上的那个）要拷到板子上，权限设为可执行。常见启动方式是：gdbserver :2345 ./my_app——监听 2345 端口，直接运行程序；如果程序已崩溃或需要 attach，改用 gdbserver :2345 --attach 。
注意：板子的防火墙（如 iptables）通常默认禁掉所有端口，得放行调试端口，否则主机连不上；另外，gdbserver 默认不输出日志，加 --once 可避免重复连接后崩溃，加 --wrapper env "LD_LIBRARY_PATH=..." -- 才能解决动态库找不到的问题。
主机 GDB 怎么连接并加载符号表
主机 GDB 必须和目标板的 gdbserver 是同一套工具链编译出来的（比如都来自 arm-linux-gnueabihf- 前缀），否则会报 Remote 'g' packet reply is too long 这类协议不匹配错误。连接命令很简单：arm-linux-gnueabihf-gdb ./my_app，进 GDB 后执行：target remote 192.168.1.100:2345（把 IP 换成你板子的实际地址）。
关键点在于符号表必须完整：你的 ./my_app 必须是未 strip 的调试版本（即编译时带 -g，链接时不加 -s 或 --strip-all）；如果用了静态链接或自定义 section，还得确认 readelf -S ./my_app 能看到 .debug_* 段。
崩溃时没 core dump 怎么定位 SIGSEGV / SIGABRT
嵌入式板子一般关了 core dump（ulimit -c 是 0），所以程序崩了就静默退出，gdbserver 也跟着断。这时别等 crash，要用 handle SIGSEGV stop print（GDB 命令）让 GDB 在信号发生时立刻停住；对 SIGABRT 同理。更实用的是提前下条件断点：break __libc_malloc if $r0 == 0（ARM32 下检查空指针 malloc）或者 watch *(int*)0xdeadbeef 监控非法地址访问。
如果已经崩了且没连上，而板子支持串口控制台，可以尝试在启动前加 echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern 并挂载 tmpfs 到 /tmp，但多数资源紧张的嵌入式环境不推荐——gdbserver + 实时中断比事后分析 core 更可靠。
为什么 stepi / next 卡住或跳转异常
这几乎一定是调试信息和实际指令不匹配导致的。典型原因有三个：gdbserver 和 GDB 版本差太多（比如 GDB 12 连 gdbserver 8.3）、优化等级太高（-O2 以上会让内联、寄存器重用、指令重排严重干扰单步逻辑）、或者代码里用了 __attribute__((optimize("O0"))) 局部关优化但头文件里没同步——结果 GDB 按源码行号找指令，实际跑的是另一段汇编。
验证方法：在停住时执行 info registers 和 x/10i $pc，对照反汇编看是否真停在你想停的地方；临时补救是切到汇编模式：set architecture arm（按实际 CPU 设定）、display/ni $pc，然后用 stepi 逐条指令走。
GDB 远程调试真正卡住的地方，往往不是连接不通，而是符号、架构、优化三者之间微妙的错位——尤其当板子跑的是旧内核（比如 3.10）而你用新 GDB（13+）时，gdbserver 的 packet 格式或寄存器命名可能已有差异，这时候翻 gdbserver --version 和 gdb --version 的输出比查文档更快。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
