必须先用file命令加载带调试信息的可执行文件，再执行target remote；否则因符号表未加载，会导致list无源码、break main失败等调试异常。
target remote 命令必须在加载符号后执行
直接运行 target remote 192.168.1.100:2345 会报错 “No symbol table is loaded”，因为 GDB 还没知道你要调试哪个程序。必须先用 file 加载本地编译的带 -g 的可执行文件，再连。
常见错误现象：(gdb) target remote 192.168.1.100:2345 后提示 Remote debugging using 192.168.1.100:2345，但 list 显示 no source，break main 失败 —— 这说明符号没加载。
-
file ./myapp（路径必须是宿主机上的、与目标板一致的带调试信息的二进制） - 再执行
target remote 192.168.1.100:2345 - 如果目标板程序已启动（attach 模式），连接成功后状态是
[New Thread ...]，不是Starting program...
IP 和端口不通时的典型表现和排查点
连接卡在 Remote debugging using ... 不动，或几秒后报 Connection refused / Operation timed out，基本就是网络或 gdbserver 侧问题。
- 目标板上确认
gdbserver确实正在监听：运行netstat -tlnp | grep :2345或lsof -i :2345 - 检查目标板防火墙：
iptables -L，临时关掉试试：iptables -F - 确认目标板 IP 是实际网卡地址（不是 127.0.0.1），且与宿主机在同一子网；用
ping和telnet 192.168.1.100 2345验证端口可达 - 某些嵌入式系统默认禁用非 loopback 的 TCP 监听，gdbserver 启动时加
--once不影响，但绑定地址不能写localhost，必须写0.0.0.0:2345或具体 IP
gdbserver 启动方式决定调试起点
你用哪种方式启 gdbserver，就决定了 GDB 连上去之后能不能用 run、要不要手动 continue。
- 全新启动：
gdbserver 192.168.1.100:2345 ./myapp arg1→ 连上后必须用continue（不是run）才能开始执行 - attach 已有进程：
gdbserver --attach 192.168.1.100:2345 1234→ 连上时进程已暂停，continue恢复运行，step可单步 - 加
--once参数：gdbserver 调试完一次自动退出，适合脚本化调试
交叉调试时容易漏掉的两个关键路径设置
即使连接成功、能下断点，也可能 step into 函数时跳过源码、print 变量显示 <optimized out></optimized> —— 这往往不是连接问题，而是符号或库路径缺失。
-
set sysroot /path/to/target/rootfs：告诉 GDB 到哪找/lib/ld-linux.so.3等系统库的符号（尤其调用 libc 函数时 backtrace 才完整） -
set solib-search-path /path/to/target/lib:/path/to/target/usr/lib：指定动态链接库路径，否则shared library loaded提示为空，info sharedlibrary看不到依赖项 - 注意：这两个路径必须是宿主机上的目录，且结构要和目标板一致（例如把整个 NFS rootfs 拷到宿主机
/opt/rootfs）
file 和 set sysroot 的顺序与路径准确性 —— 它们不报错，但会让断点命中、变量查看、栈回溯全部失效，看起来像“连上了却调不了”。 
