gdbserver启动后程序立即退出是因默认不暂停，需在程序入口加raise(SIGSTOP)或用--once配合LD_PRELOAD挂起；VS Code调试须正确配置miDebuggerPath、miDebuggerServerAddress和sourceFileMap路径映射；多进程需手动设follow-fork-mode和detach-on-fork；变量显示<optimized out>源于-O2以上优化，应编译时用-O0 -g3。
gdbserver 启动后程序立即退出，连不上怎么办
常见现象是 gdbserver :2345 ./myapp 执行完就报 Process ./myapp created; pid = 1234 然后直接退出，没等 gdb 连。这不是 bug，是默认行为：gdbserver 启动目标进程后，**不暂停、不等待断点，直接运行到结束**。
正确做法是加 --once（可选）+ --attach 或更常用的是用 --once 配合 kill -STOP 提前挂起进程，但最稳的还是让程序自己停在入口：
- 在目标程序开头插入
raise(SIGSTOP)（需#include <signal.h>），编译后运行gdbserver :2345 ./myapp，它会卡住，此时 gdb 就能连 - 或者用
gdbserver --once :2345 --wrapper env LD_PRELOAD=/path/to/libstop.so -- ./myapp，但太重，不推荐 - 避免用
--attach调试新进程——它只适用于已运行的 PID，对刚启动的 main 不友好
VS Code 的 launch.json 怎么配才不连错端口或路径
远程调试失败八成出在路径映射和端口转发上。VS Code 本身不直连目标机，它通过本地 gdb（如 arm-linux-gnueabihf-gdb）连 gdbserver，中间可能跨 SSH，所以必须明确三段路径：
-
miDebuggerPath指向你本地的交叉 gdb，不是系统自带的gdb；比如嵌入式开发就得写/opt/gcc-arm/bin/arm-linux-gnueabihf-gdb -
miDebuggerServerAddress格式必须是target_ip:port，不能带localhost或127.0.0.1（那是你本机，不是目标机） -
sourceFileMap是关键：把本地源码路径（如/home/dev/project/src/）映射到目标机绝对路径（如/root/project/src/），少一个斜杠或大小写错，断点就无效
示例片段：
立即学习“C++免费学习笔记（深入）”；
"sourceFileMap": {
"/home/user/myproj/": "/opt/myapp/"
}gdb 连上 gdbserver 后 set follow-fork-mode 无效
这是典型多进程场景下的坑：目标程序 fork 出子进程后，gdb 默认只跟 parent，子进程的符号、断点全丢。你以为打了断点，其实断在 parent 里，子进程飞走了。
解决必须在连接后、运行前设置：
- 连上后立刻执行
set follow-fork-mode child（跟子进程）或set follow-fork-mode parent（默认） - 加
set detach-on-fork off，否则 gdb 会自动 detach 子进程，导致无法控制 - 如果子进程还 exec 了新程序，得额外设
set follow-exec-mode new，不然符号表加载失败
这些命令不能写在 .gdbinit 里就完事——gdbserver 模式下，很多 init 命令不生效，必须手动敲或塞进 VS Code 的 setupCommands 数组里。
为什么断点命中但变量显示 <optimized out>
不是远程问题，是编译选项惹的祸。只要目标程序用了 -O2 或更高优化级，gcc/g++ 会内联函数、复用寄存器、删临时变量，gdb 就真找不到原始值了。
- 调试版务必加
-O0 -g3 -fno-omit-frame-pointer；-g3包含宏和内联展开信息，比-g更全 - 嵌入式环境常为省空间开
-Os，它也会导致大量<optimized out>，别忍，换-O0 - 检查是否误用了
strip：部署时 strip 掉了 debug info，gdbserver 就只剩二进制，自然读不到变量名
远程调试不放大这个问题，但它会让问题更难排查——你没法像本地那样快速重编再试。
