远程调试前须确认gdbserver支持多线程：查看--version含thread/posix、启动日志有Created thread、构建时启用BR2_PACKAGE_GDBSERVER且未禁用threading；连接后立即执行info threads验证线程可见性；切换线程后需frame 0或list $pc同步源码上下文；thread apply all慎用，优先set scheduler-locking on后再执行。
远程调试前必须确认目标机 gdbserver 支持多线程
很多嵌入式设备默认安装的 gdbserver 是精简版（如 gdbserver-nosyscall），它不支持 info threads 或线程切换，强行调试会卡在 Thread ID 1 not known 或直接拒绝连接。确认方式很简单：
- 在目标机上运行：
gdbserver --version，输出中应含thread或posix字样； - 启动时加
--once并观察是否打印Listening on port ...后有类似Created thread ...的日志； - 若用 Buildroot/Yocto 构建，确保启用了
BR2_PACKAGE_GDBSERVER且未勾选disable threading配置项。
不满足条件就换完整版 gdbserver，别试图用 set follow-fork-mode 换取线程可见性——那只是掩耳盗铃。
target remote 连接后立即执行 info threads
远程连接成功不等于线程信息已加载。GDB 默认只在首次触发断点或收到线程事件时才拉取线程列表，所以连接后务必手动执行：
-
target remote 192.168.1.100:2345（先连上） -
info threads（立刻查，看是否列出多个Thread 2 (LWP ...)） - 如果只显示
Thread 1，说明程序尚未创建其他线程，或gdbserver未上报——此时可先continue让程序跑起来再试一次info threads。
注意：info threads 输出中的 LWP ID（轻量级进程 ID）就是 Linux 下的 gettid() 值，和 /proc/<pid>/task/</pid> 下目录名一致，可用于交叉验证。
切换线程后，bt 和 list 仍可能显示错位
这是最常被忽略的坑：GDB 切换线程（thread 2）后，bt 能正确显示该线程调用栈，但 list 默认仍定位到主线程当前行号对应的源码位置，而非当前线程停在哪儿。
- 正确做法是：切换线程后，先执行
frame 0（回到栈顶帧），再list； - 或者直接
list $pc，强制按当前线程的程序计数器地址显示源码； - 若看到
??或乱码，说明该线程执行的是优化后的汇编（比如pthread_create启动的函数没加-g），需检查所有线程入口函数是否都编译进了调试信息。
多线程调试里，“当前线程”和“当前源码上下文”是两个独立状态，GDB 不会自动同步它们。
用 thread apply all 批量操作时小心副作用
thread apply all bt 看起来很爽，但实际执行时，GDB 会逐个暂停所有线程再恢复——这可能导致竞态条件被掩盖，或让正在等待锁的线程意外唤醒。
- 安全替代方案：
thread apply all p/x $pc（只读寄存器，无副作用）； - 真要查所有栈，优先用
set scheduler-locking on锁定调度器，再thread apply all bt； - 避免在生产环境用
thread apply all call some_func()——跨线程调用函数极可能 crashgdbserver。
远程环境下，网络延迟会让 thread apply all 的暂停/恢复周期拉得更长，更容易干扰被调程序行为。
