如何快速区分断点触发的SIGTRAP与ptrace引发的SIGTRAP？

不用维护调试器状态、不用遍历断点的核心方法，是利用内核通过waitpid和ptrace接口暴露的信号元数据和事件信息：

1. 检查SIGTRAP的si_code字段 #

当进程停止时，先调用ptrace(PTRACE_GETSIGINFO, pid, NULL, &siginfo)获取信号的详细信息，通过siginfo_t结构的si_code字段区分：

• 断点触发的SIGTRAP：
  • 软件断点（如x86的int3指令）：si_code == TRAP_BRKPT
  • 硬件断点/观察点：si_code == TRAP_HWBKPT
• ptrace主动操作引发的SIGTRAP：
  • 单步执行（PTRACE_SINGLESTEP）导致的停止：si_code == TRAP_TRACE

2. 识别ptrace事件型停止 #

对于PTRACE_SYSCALL、PTRACE_ATTACH这类操作导致的进程停止，虽然表面上也是SIGTRAP，但属于ptrace的事件通知，可通过以下方式区分：

• 从waitpid返回的status中提取事件类型：(status >> 16) == PTRACE_EVENT_*（比如PTRACE_EVENT_SYSCALL对应系统调用停止）
• 调用ptrace(PTRACE_GETEVENTMSG, pid, NULL, &event_msg)获取事件的附加数据，进一步确认停止原因是ptrace主动请求而非断点

为什么这比维护状态可靠 #

内核直接提供的这些元数据是权威的，不会因为调试器与被调试进程之间的异步操作（比如信号延迟、意外中断）而失效，完全不需要自己记录“是否发起过ptrace请求”这类脆弱的状态。

内容的提问来源于stack exchange，提问作者carmius