gdbserver启动后程序未运行是因仅监听端口而不自动执行目标程序；必须指定绝对路径和参数，如gdbserver 192.168.1.200:2345 /opt/app/test --log-level=debug，并确保网络连通、交叉gdb架构匹配、符号完整且用continue而非run启动。
gdbserver 启动时必须指定目标程序路径和参数
连接失败最常见的原因是 gdbserver 没有真正启动目标进程——它只是监听端口，不自动运行程序。你得在目标设备上明确告诉它「运行哪个可执行文件、带什么参数」。
例如，目标板 IP 是 192.168.1.200，要调试的程序是 /opt/app/test，且需传参 --log-level=debug，命令必须写成：
gdbserver 192.168.1.200:2345 /opt/app/test --log-level=debug
注意：gdbserver 启动后会输出类似 Process /opt/app/test created; pid = 123 的提示，这才是进程已跑起来的标志。如果只看到 Listening on port 2345 就停住，说明路径错了、权限不足，或动态库缺失导致加载失败。
- 路径必须是绝对路径；相对路径（如
./test）在无 shell 环境下大概率失败 - 确保目标程序已用
-g编译，且未被strip过（否则 gdb 无法读符号） - 若程序依赖共享库，
gdbserver不负责加载它们——得提前把.so放到目标板对应路径，或用LD_LIBRARY_PATH指定
target remote 必须匹配 gdbserver 监听地址和端口
target remote 命令不是“连上就行”，它要求宿主机能真实 TCP 连通目标板的端口。很多问题其实卡在底层网络，而不是 GDB 配置本身。
在宿主机上运行：
arm-linux-gnueabihf-gdb ./test (gdb) target remote 192.168.1.200:2345
如果报错 Connection refused 或卡住不动，先别调 gdb，做三件事：
- 在宿主机上用
nc -zv 192.168.1.200 2345测试端口是否可达 - 确认目标板防火墙没拦：临时关掉
iptables或nft规则 - 检查
gdbserver是否真在监听：目标板上运行netstat -tuln | grep 2345，应有LISTEN状态
特别注意：有些开发板默认禁用非本地回环的 TCP 连接，需确认内核参数 net.ipv4.tcp_syncookies 或 net.ipv4.conf.all.accept_redirects 没误设。
交叉编译 gdb 客户端必须与目标架构对齐
宿主机上运行的 gdb 不是系统自带那个 gdb，它必须是为你的目标平台（比如 aarch64-linux-gnu 或 arm-linux-gnueabihf）专门编译的版本。用错会导致 Cannot access memory at address、断点不命中，甚至直接 segfault。
验证方式很简单：
arm-linux-gnueabihf-gdb --version # 输出中应包含 "This GDB was configured as \"--target=arm-linux-gnueabihf\""
如果显示的是 x86_64-pc-linux-gnu，说明你用错了二进制。
- CLion 和 VS Code 默认使用捆绑 GDB，但需在设置里手动指定路径，不能依赖 PATH 查找
- VS Code 的
launch.json中miDebuggerPath必须指向交叉 gdb，不是/usr/bin/gdb - CLion 的 Remote Debug 配置里，“GDB path” 字段要填完整路径，比如
/opt/arm-gdb/bin/arm-linux-gnueabihf-gdb
连接后必须用 continue 启动，不能用 run
这是新手最常踩的坑：以为远程调试和本地一样，输入 run 就能跑程序。实际上，gdbserver 已经把进程拉起来了，gdb 只是 attach 上去。此时 run 会报错 The program is not being run 或直接重启进程，破坏调试上下文。
正确流程是：
(gdb) target remote 192.168.1.200:2345 (gdb) b main (gdb) c # 注意：是 c（continue），不是 run
c 的作用是让已挂起的目标进程继续执行，从断点处开始；而 run 是启动一个全新进程，这在远程模式下无意义，且会因缺少环境变量、工作目录等失败。
另外，如果程序一启动就崩溃，建议先用 set follow-fork-mode child，避免 fork 后 gdb 跟丢子进程。
真正麻烦的从来不是命令怎么敲，而是哪一层出了问题：是程序根本没跑起来？网络不通？gdb 架构不匹配？还是调试符号丢了？每次连不上，按「gdbserver 输出 → 网络连通性 → gdb 客户端架构 → 符号文件存在性」这个顺序查，比反复改 launch.json 有效得多。
