gdbserver 启动时无法直接指定工作目录，其被调试进程的当前工作目录继承自 gdbserver 自身的启动目录；最稳妥做法是在目标设备上先 cd 到目标目录再执行 gdbserver，或使用 wrapper 脚本显式切换并 exec 启动。
gdbserver 启动时无法直接指定工作目录
gdbserver 本身不支持 --chdir 或类似参数来设置被调试程序的当前工作目录。它只负责加载并托管进程，工作目录由启动方式决定——也就是说，**工作目录继承自 gdbserver 进程自身的当前目录**。
常见错误现象：断点命中后 print getcwd() 返回 /tmp，但你期望是 /home/app；或打开配置文件失败，提示 No such file or directory，实际是因为相对路径基于错误目录解析。
- 最稳妥的做法：在目标设备上先
cd到目标目录，再执行gdbserver - 例如：
cd /home/app && ./gdbserver :1025 ./myapp - 如果通过脚本或 systemd 启动，确保
WorkingDirectory=已正确配置（systemd）或使用cd显式切换 - 避免用绝对路径启动 gdbserver 后靠
set cwd补救——GDB 客户端的cd命令只影响 GDB 自身的源码/符号查找路径，不影响被调试进程的实际工作目录
GDB 客户端里 cd 命令的作用范围很有限
在 PC 端运行 gdb 后输入 cd /home/app，这只是让 GDB 在查找源文件、读取 .gdbinit、解析相对路径的 file 或 symbol-file 时使用该目录。它**完全不会修改目标进程的 cwd**。
验证方法：在 GDB 中执行 shell pwd 看的是 GDB 进程的工作目录；而 call (int)chdir("/home/app") 才能真正修改被调试进程的当前目录（需进程仍在运行且有权限）。
- 如果你只是想让
list正确显示源码，用directory /path/to/src更可靠 - 若需在调试中动态切目录（比如重定向日志到某路径），可在 GDB 中执行
call chdir("/target/dir")，但注意这属于侵入式操作，可能影响程序逻辑 -
set cwd不是标准 GDB 命令，部分前端（如 Qt Creator）可能提供封装，但底层仍依赖上述机制
自动化部署场景下推荐用 wrapper 脚本控制目录
当通过 Qt Creator、VS Code 或 CI 部署调试时，手动 cd 不现实。这时应在目标设备上写一个轻量 wrapper 脚本，显式切换并启动：
#!/bin/sh cd /opt/myapp || exit 1 exec /usr/bin/gdbserver "$@"
然后在主机端连接时指向该脚本：target remote 192.168.11.25:1025，前提是脚本已设为可执行并传到板端。
- 注意
exec的使用：它用 gdbserver 替换当前 shell 进程，避免多一层 shell 导致getcwd()返回 wrapper 所在目录 - 不要在 wrapper 中后台运行 gdbserver（如加
&），否则 GDB 客户端会因连接立即断开而报Connection refused - 若使用 NFS 挂载，确保挂载点在 wrapper 执行前已就绪，否则
cd失败静默退出
真正容易被忽略的是：gdbserver 的工作目录和被调试程序的 cwd 是同一回事，但很多人误以为 GDB 客户端能“远程 cd”。实际必须从启动源头控制——要么提前 cd，要么用 wrapper，要么在程序内部用 chdir() 初始化。没有中间态。
