Where would the CPU context interrupted by ptrace be, userspace stack or kernel stack?

Question

On Linux x86_64, when I use ptrace to stop a process, would all the threads' CPU contexts would be saved, or just the process's CPU context be saved?

Is the context on process's userspace stack or kernel stack? Or somewhere else? Or multiple copies?

For other situations (not ptrace), where could the interrupted (including exception and syscall) CPU context saved, kernel stack, userspace stack or somewhere else?

Is ptrace an interrupt?

---

Update

It seems that, ptrace's context pt_regs_x86_t, where to save is determined by the programmers. But would the kernel also stores a copy for the interrupted context?

Answer 1

Yes, the kernel will always store context for any thread that is not currently executing. That context is largely the same whether the thread is being ptrace'd or not. The difference is in how/whether the thread can be scheduled anew -- if it's being ptraced, the tracing process will decide when it can be resumed.

The thread's user-space context is stored on the kernel stack (but it's important to note that there is a separate kernel stack area for each thread). And that will be the same whether the thread entered the kernel by executing a system call, or was suspended due to an interrupt -- and ultimately, those are the only two ways a thread can be suspended.

As you discovered, when a process is ptrace'd, the tracing program is given access to the traced threads' registers in the state they had when the threads last executed. That is accomplished by simply copying the saved registers from the traced thread's kernel stack.

Finally, it's worth noting that if you look at linux kernel code, you won't find any concrete representation of a process. A process is just a group of related threads that share various parts of their state: process ID, address space, file descriptors, etc.