【问题标题】:Where would the CPU context interrupted by ptrace be, userspace stack or kernel stack?ptrace 中断的 CPU 上下文在哪里,用户空间堆栈或内核堆栈?
【发布时间】:2015-04-22 17:26:57
【问题描述】:

在 Linux x86_64 上,当我使用 ptrace 停止进程时,会保存所有线程的 CPU 上下文,还是只保存进程的 CPU 上下文?

上下文是在进程的用户空间堆栈还是内核堆栈上?或者别的地方?还是多份?

对于其他情况(不是 ptrace),中断(包括异常和系统调用)的 CPU 上下文、内核堆栈、用户空间堆栈或其他位置可以保存在哪里?

ptrace 是中断吗?


更新

看来,ptrace的上下文pt_regs_x86_t,保存在哪里是程序员自己决定的。但是内核是否也会为中断的上下文存储一份副本?

【问题讨论】:

    标签: linux exception linux-kernel interrupt ptrace


    【解决方案1】:

    是的,内核将始终为当前未执行的任何线程存储上下文。无论线程是否被 ptrace'd,该上下文在很大程度上是相同的。不同之处在于如何/是否可以重新调度线程——如果它正在被 ptrace 跟踪,则跟踪进程将决定何时可以恢复它。

    线程的用户空间上下文存储在内核堆栈中(但重要的是要注意每个线程都有一个单独的内核堆栈区域)。无论线程是通过执行系统调用进入内核还是由于中断而被挂起,这都是一样的——最终,线程可以被挂起的仅有两种方式。

    正如您所发现的,当一个进程被 ptrace'd 时,跟踪程序可以访问被跟踪线程的寄存器,这些寄存器处于线程上次执行时的状态。这是通过简单地从跟踪线程的内核堆栈中复制保存的寄存器来完成的。

    最后,值得注意的是,如果您查看 linux 内核代码,您将找不到任何进程的具体表示。进程只是一组相关的线程,它们共享其状态的各个部分:进程 ID、地址空间、文件描述符等。

    【讨论】:

    • 这里的异常和int 0x80包含在中断中,对吧?而且这里的 syscall 就是 sysenter/sysexit 的意思吧?
    • 是的,有实际中断(由外部事件/设备引起)、用户进程直接调用的陷阱(sysenter、int 0x80等)和用户代码行为引起的陷阱或错误(页面错误) ,除以零,分段违规等)。但所有结果都会在内核中保存相同类型的上下文。
    • 内核代码导致的故障怎么办?
    • ptrace() PTRACE_SETREGS 可以用于单个线程,而不仅仅是进程,对吧?
    猜你喜欢
    • 2022-01-05
    • 2013-05-10
    • 2016-11-06
    • 2011-12-10
    • 2014-10-04
    • 2020-04-25
    • 2015-03-11
    • 2012-09-08
    • 2014-04-21
    相关资源
    最近更新 更多