gdbserver启动时必须在目标设备上直接传参，格式为gdbserver [host:port] program [args...]，参数和环境变量均需在目标端设置，远程调试中run无效，应使用continue继续执行。
gdbserver 启动时传参，不是在 gdb 里 run
远程调试中，gdb 本地不负责启动目标程序，所以 run 或 set args 在连接 gdbserver 后无效。参数必须在目标设备上由 gdbserver 启动时指定。
-
gdbserver命令格式是：gdbserver [host:port] program [args...]，所有[args...]都会原样传给program - 环境变量（如
LD_LIBRARY_PATH）也需在目标设备上提前设置，gdbserver不继承宿主机的环境 - 如果参数含空格或特殊字符，需在目标设备 shell 中正确引号包裹，例如：
gdbserver :2345 ./app "--input=file name.txt" --verbose - 调试带 stdin 输入的程序时，
gdbserver默认接管标准输入；若需交互式输入，建议用--once模式并配合重定向，或改用target extended-remote+attach方式
为什么 target remote 之后不能用 run？
因为 target remote 连接的是已由 gdbserver 启动的调试会话，此时进程状态已是“已加载、暂停在入口”或“等待首次连接”。run 命令只适用于本地未启动的进程，远程模式下它会报错：The program is not being run 或直接忽略。
- 正确做法是连接后直接用
continue（简写c）——这等价于“继续执行被gdbserver暂停的程序” - 若想在 main 入口停住再开始，确保
gdbserver启动时不加--once，且在 gdb 中先break main再continue -
set args在远程会话中不会报错，但完全不起作用；可用show args验证，它显示的只是本地 gdb 的无关缓存值
常见参数传递失败现象
程序运行时提示 “missing argument”、“unknown option”，或 argv[1] 为空，大概率不是 gdb 配置问题，而是参数根本没传到目标进程。
- 检查目标设备上
ps aux | grep your_program，确认看到的命令行是否包含你期望的参数 - 注意 shell 转义：比如
gdbserver :1234 ./a.out -c config.json中，若config.json路径含空格，不加引号会导致参数截断 - 交叉编译环境容易忽略：目标设备的
libc版本可能不支持某些 getopt 行为，参数解析失败与 gdb 无关，但现象类似 - 使用
gdbserver --multi模式时，首次连接后程序才启动，此时参数仍由gdbserver命令行决定，不是由 gdb 控制
调试带参数的 C++ 程序时的典型流程
以 ./demo --mode=debug --log-level=3 为例，完整链路必须严格分清宿主和目标两段操作：
- 目标设备（开发板/ARM 设备）：
export LD_LIBRARY_PATH=/usr/lib:/app/lib && gdbserver :9999 ./demo --mode=debug --log-level=3 - 宿主机（x86 Linux）：
arm-linux-gnueabihf-gdb ./demo→(gdb) target remote 192.168.1.100:9999→(gdb) break main→(gdb) continue - 关键点：两个
./demo必须完全一致（路径、符号表、架构），否则break main可能命中错误位置，甚至无法解析源码行号 - 若程序立即崩溃，可在
gdbserver后加--wrapper strace --（需目标设备有 strace）辅助定位参数解析阶段的问题
gdbserver 启动命令的完整输出——它会打印 “Process ./demo created; pid = XXX”，紧接着列出收到的全部 argv。没看到预期参数，就不用往下试 gdb 命令了。 
