【发布时间】：2015-07-17 07:07:09
【问题描述】：
线程 A 可以读取线程 B 的程序计数器寄存器的值（在 C 或 C++ 程序中，在 64 位 Intel 架构的 Linux 下运行），而无需对线程 B 的代码进行任何特殊检测?
（我意识到这是一件奇怪的事情；这个愿望只是因为我很好奇线程 A 是否可以使用它来检测线程 B 是否陷入失败的系统调用，如 here 所述)
【问题讨论】：
标签： c linux multithreading program-counter
【发布时间】：2015-07-17 07:07:09
【问题描述】：
在 Linux 上，/proc/self/task/%d/stat 的第 30 字段，其中%d 需要填写相关线程的内核 tid，其中包含线程的最后观察到的指令指针值。请参阅http://man7.org/linux/man-pages/man5/proc.5.html 并注意它记录在/proc/[pid]/stat 下，但当前进程下task 目录中的版本是您想要针对线程的版本。
困难的部分可能是获取线程的内核 tid。最简单的方法是从线程调用syscall(SYS_gettid) 并将其内核 tid 存储在某处。
【讨论】：
-
对于给定的进程，如果目标是找到 any 卡住的线程，检查任务目录中列出的所有 TID 就足够了 - “TID X 似乎卡在 PC 值 Y ”。 TID 值真的无关紧要。但是，如果 PC 值是用于该线程阻塞的“正常”位置，这并不能避免误报。
-
是的。 OP 在这里可能会出现 XY 问题，因为所需的机制并不是解决问题的好方法。但我仍然认为值得回答，因为请求的机制有解决方案。
-
R.. 同意我可能确实有一个 XY 问题......我真正想要的是内核“oops”干净地使我的进程崩溃，而不是强迫我的其他线程跳转通过箍来确定主线程是否已经永远瘫痪，以及是否应该因此使进程本身崩溃以允许进程重新启动。但似乎不太可能存在控制这种行为的设施。 :(
-
顺便说一句，您还可以将堆栈指针作为字段 29。这可能是一些额外的信息，可以帮助您弄清楚发生了什么。堆栈指针和指令指针甚至可能足以使用适当的展开库代码对目标线程进行回溯。