info registers只显示当前线程的寄存器快照，不包含任何线程标识信息；要确认所属线程，须先用info threads查看带*号的当前线程ID，再结合gs_base等寄存器判断TLS上下文。
gdb里info registers不显示线程信息，别白试
直接说结论：info registers只显示当前线程的寄存器快照，它本身不含任何线程标识字段（比如TID、LWP、TLS基址），更不会列出“这是哪个线程的寄存器”。你执行它时看到的只是当前线程上下文的通用寄存器（rax, rbp, rip等）和状态寄存器，和单线程程序完全一样。
想确认当前寄存器属于哪个线程？唯一可靠方式是先用info threads看清楚当前线程ID（带*号那行），再切过去执行info registers——寄存器内容本身不自证身份。
真正能暴露线程上下文的寄存器相关命令
某些架构（如x86-64 Linux）中，线程局部存储（TLS）基址会存放在特定寄存器里。例如：
-
gs_base（x86-64）或fs_base（x86）寄存器保存了当前线程的TLS段起始地址 - 用
info registers gs_base可直接读出该值；对比不同线程的gs_base，数值不同即说明TLS隔离生效 - 注意：
gs_base不是标准info registers默认输出项，必须显式指定寄存器名才能查看
为什么thread_local变量地址和gs_base有关
编译器生成thread_local变量访问代码时，通常用类似mov rax, QWORD PTR gs:[0x10]的方式计算地址——即“gs_base + 偏移”。所以：
立即学习“C++免费学习笔记（深入）”；
- 若
print &my_tls_var返回的地址和gs_base差值稳定（如+16、+32），说明TLS机制正常工作 - 若多个线程
gs_base相同，或&my_tls_var地址跨线程一致，基本可断定编译漏了-pthread -
gs_base本身不能被set修改，它是内核在线程切换时自动加载的，GDB只能读取
调试时容易忽略的关键点
寄存器视角下的线程调试，最常踩的坑不是命令不会用，而是误把寄存器当成线程元数据容器：
-
info registers从不输出线程ID、LWP、名字或状态——这些全靠info threads提供 -
gs_base或fs_base虽反映线程上下文，但它们是CPU寄存器，不是GDB维护的“线程属性”，切换线程后需重新读 - 在
thread apply all批量执行命令时，info registers gs_base会为每个线程分别输出，但GDB不会自动标注哪行对应哪个线程ID，得自己对照info threads序号
