thread -1 可快速切回最近一次手动切换的线程（非系统调度意义上的“上一个”），其 ID 来自 info threads 第一列；若该线程已退出则报错，gdb 本身不记录调度历史。
gdb 中没有“上一个执行的线程”这个概念
gdb 本身不记录线程调度历史，thread apply all bt 或 info threads 只能看当前状态，无法回溯“刚刚在哪个线程停过”。所谓“跳转到上一个线程”，实际是指：**快速切回你最近手动切换过的那个线程**，而不是操作系统调度意义上的“上一个运行线程”。
用 thread 命令配合历史编号最可靠
gdb 会为每个 thread N 切换操作生成命令历史，但更直接的是利用线程 ID 的连续性与 gdb 自带的快捷方式：
-
thread -1：切换到上一次 显式切换过 的线程（不是上一个被调度的线程，而是你上次敲过thread 3之后再敲thread -1，就会回到之前那个） -
thread <id>中的<id>是 gdb 内部编号（info threads第一列），不是系统 tid（pthread_self()或/proc/pid/status里的 tid） - 如果中途执行过
continue或step导致断点命中在别的线程，thread -1仍指向你上次手动选中的线程，不会自动更新
调试时让线程切换更可预测的实操建议
避免依赖“上一个”，主动控制上下文：
- 在关键断点处用
thread info或print $_thread记下当前线程号，后续可直接thread 7 - 给线程起名（C++11+）：
std::thread t([]{...}); t.native_handle();配合pthread_setname_np，然后在 gdb 里用info threads看名字，比纯数字好识别 - 用
set scheduler-locking on锁定当前线程，防止单步时被其他线程抢占——这时“上一个”就真的只可能是你自己刚切的那个 - 慎用
thread apply all批量操作，它可能掩盖线程间状态差异；优先thread 2→bt→thread 3→bt这样逐个确认
为什么 thread -1 有时不按预期工作
常见陷阱：
立即学习“C++免费学习笔记（深入）”；
- 你在某线程 hit 断点后没手动
thread切换，直接continue，下一个断点停在另一线程——此时thread -1仍指向最初那个，不是你“以为的上一个” - 使用
record/reverse-step时，线程上下文不随反向执行更新，thread -1保持静态 - 多级函数调用中嵌套
std::async或std::jthread，线程创建快、消亡快，info threads列表动态变化，-1指向的线程可能已退出（gdb 会报Thread ID 5 has terminated）
真正需要追溯调度顺序时，得靠外部手段：加 __builtin_dump_struct(this, &std::cout) 日志、用 perf record -e sched:sched_switch、或在代码里用 syscall(SYS_gettid) 打点。gdb 不是调度追踪器。
