PTRACE_GETREGS 返回-1并报EIO，是因为目标进程未处于可读寄存器的停止状态；必须先用waitpid等待WIFSTOPPED成立，确保进程已稳定暂停，再调用才有效。
为什么 PTRACE_GETREGS 会返回 -1 并报 EIO？
直接调用 PTRACE_GETREGS 失败，大概率不是权限或参数错，而是目标进程没真正处于「可读寄存器」状态。Linux 要求被跟踪进程必须已停止（stopped），且不能是信号挂起（signal-pending）但尚未交付的状态。常见于：刚发 ptrace(PTRACE_CONT, pid, nullptr, SIGSTOP) 后立刻读寄存器——此时进程可能还在内核态切换中，waitpid() 没返回，PTRACE_GETREGS 就必然失败并设 errno = EIO。
- 必须先用
waitpid(pid, &status, 0)等待子进程进入WIFSTOPPED(status)状态 - 断点命中后，进程通常停在断点指令地址的**前一条指令处**（x86_64 下，
rip指向断点指令本身；ARM64 则因取指流水线差异略有不同） - 如果目标进程是多线程，需确保 attach 的是正确线程（
tid而非pid），否则PTRACE_GETREGS对非当前线程无效
struct user_regs_struct 的字段和平台差异怎么处理？
struct user_regs_struct 不是标准 C++ 类型，它由系统头文件定义（如 sys/user.h），字段名、大小、顺序随架构变化极大。x86_64 上有 rip, rsp, rax 等；aarch64 上是 pc, sp, x0… 直接硬编码字段名会跨平台崩溃。
- 编译时用
#ifdef __x86_64__或#ifdef __aarch64__分支访问对应寄存器字段 - 不要假设
sizeof(struct user_regs_struct)固定；某些内核版本对 SVE 支持会扩展该结构，PTRACE_GETREGS可能被PTRACE_GETREGSET替代 - 若需兼容旧内核（PTRACE_GETREGSET +
NT_PRSTATUS，老系统不识别该请求码
读寄存器前要不要先单步跳过断点指令？
不需要。断点命中后，进程暂停在断点处，此时寄存器反映的是断点触发瞬间的真实上下文（比如 rip 就是指向 int3 指令）。如果你马上读 rip，它就是断点地址；你若想让它“继续执行断点指令”，才需要手动恢复内存（把原始字节写回去）、单步（PTRACE_SINGLESTEP）、再恢复断点——这是调试器实现逻辑，和读寄存器本身无关。
- 读寄存器只是快照，不改变目标状态
- 若目标进程在断点处被
SIGTRAP中断，siginfo_t.si_addr一般也等于rip，可交叉验证 - 注意：GDB 默认在断点后自动单步一次以避开
int3，所以它显示的rip是下一条指令——这不是内核行为，是 GDB 自己做的
完整最小可行代码里最容易漏掉哪一步？
漏掉 ptrace(PTRACE_SETOPTIONS, pid, nullptr, PTRACE_O_TRACESYSGOOD) 或类似选项，导致 waitpid() 返回的 status 无法区分是正常停止还是被信号中断。更隐蔽的是：没检查 WSTOPSIG(status) 是否为 SIGTRAP，就直接读寄存器——结果可能是进程因其他信号（如 SIGCHLD）暂停，此时寄存器内容虽可读，但语义完全不对。
立即学习“C++免费学习笔记（深入）”；
- 必须确认
WSTOPSIG(status) == SIGTRAP再进行寄存器读取 -
PTRACE_GETREGS第四个参数必须是非空指针，传nullptr会导致EINVAL - 目标进程需已通过
ptrace(PTRACE_ATTACH, pid, nullptr, nullptr)或fork()+exec配合PTRACE_TRACEME进入被跟踪状态，否则所有 ptrace 调用都失败
寄存器上下文不是随时可取的快照，它是内核在特定暂停语义下维护的一组临时状态。一旦进程状态迁移（比如被 PTRACE_CONT 唤醒），这组值就失效了；而重新捕获它，又得走一遍 waitpid → 校验信号 → 读取的闭环。这个闭环里任何一环松动，拿到的就不是你想要的那个“断点时刻”。
