先解释名字。Mono 有两代调试器Hard Debugger走操作系统层ptrace、硬件调试寄存器依赖平台、依赖 GDB 那套早已废弃。Soft DebuggerSDB调试逻辑内嵌进 Mono 运行时本身由运行时主动配合调试器。soft就是指它不依赖 OS 级的硬件/内核调试设施而是软件层自我插桩。Unity 的托管代码调试VS、Rider 连上去打断点走的就是 Soft Debugger。所以理解它本质是理解一个问题在没有 ptrace、没有硬件断点的前提下一个 JIT 编译的托管程序怎么做到在某个源码行精确停下、看变量、单步整篇就围绕这个问题展开。一、整体架构调试器住在运行时里┌─────────────┐ Wire Protocol ┌──────────────────────┐ │ IDE 前端 │ ◄───── (TCP Socket, 异步) ─────► │ Mono Runtime │ │ VS / Rider │ 在 Foo.cs:42 设断点 │ ┌─────────────────┐ │ │ │ 读取局部变量 x │ │ Debugger Agent │ │ └─────────────┘ 线程停在哪了 │ │ (内嵌线程) │ │ │ └────────┬────────┘ │ │ │ │ │ ┌────────▼────────┐ │ │ │ JIT / 执行引擎 │ │ │ └─────────────────┘ │ └──────────────────────┘启动时通过运行时参数注入这个 agentmono --debugger-agenttransportdt_socket,address127.0.0.1:56000,servery YourGame.exeDebugger Agent是运行时里的一个独立线程它监听 socket收 IDE 的命令设断点、读栈、继续运行……在被调试线程命中断点时把它们挂起然后把状态回报给 IDE命令和事件通过Soft Debugger Wire Protocol收发关键点调试器和被调试程序在同一个进程里靠内部机制通信而不是像 GDB 那样一个进程盯着另一个进程。二、断点落在哪Sequence Point序列点你在 IDE 里点的是Foo.cs:42但运行时执行的是 IL / native code。中间需要一座桥——序列点。序列点是 IL 代码中被标记为可安全观测的位置它把源码行列 ↔ IL 偏移关联起来。JIT 编译时又进一步记录IL 偏移 ↔ native 机器码地址。Foo.cs 第42行 │ debug info: .pdb / .mdb 提供映射 ▼ 方法 FooIL offset 0x1A ← 这是一个序列点 │ JIT 编译时记录 ▼ native code 地址 0x7fff...c30序列点通常出现在每个方法入口method entry每个return之前method exit每条源码语句对应的 IL 起始处显式的Debugger.Break()位置所以设断点这个动作在运行时内部被翻译成在方法Foo的 IL offset0x1A这个序列点上让执行停下来。如果一个方法没有 debug info、没生成序列点你就打不上断点——这也是Release 构建 / 剥离了 pdb 就没法打断点的根本原因。三、核心魔法怎么让 native 代码停下来这是最精妙的部分。Soft Debugger 不改指令流、不插int3那是 hard 调试器干的而是用了一个内存保护页 信号的技巧。两个特殊内存页运行时启动时分配两个特殊页breakpoint trigger page断点触发页single-step trigger page单步触发页JIT 编译带调试信息的方法时会在每个序列点插入一条对这两个页的内存读取指令; 序列点处 JIT 生成的伪代码 mov rax, [ss_trigger_page] ; 读单步触发页为单步准备 ; ... 该序列点对应的实际业务指令 ...平时这两个页是可读的读一下什么也不发生几乎零开销。启用断点/单步 把页设成不可访问当 IDE 要求在此处停下时agent 调用mprotect把对应触发页改成不可读正常运行 启用断点后 ss_trigger_page: [ 可读 ] ──mprotect──► [ 不可访问 ] │ │ 执行到序列点读它: 读成功继续 执行到序列点读它: 触发 SIGSEGV于是执行流跑到序列点、去读那个页时触发 SIGSEGV段错误。信号处理器接管Mono 装了自己的 SIGSEGV 处理器。它一看出错地址正好是触发页就知道“这不是真崩溃这是一次调试断点/单步事件”// 概念示意signal_handler(fault_addr){if(fault_addrbp_trigger_page)// 是断点触发mono_debugger_agent_breakpoint_hit(ctx);elseif(fault_addrss_trigger_page)// 是单步触发mono_debugger_agent_single_step_event(ctx);elsereal_crash();// 真的崩了}接着挂起命中的线程以及按策略挂起其他线程通过序列点信息反查出当前的方法、IL 偏移、源码行把断点命中事件通过 wire protocol 发给 IDEIDE 收到后展示调用栈、局部变量……都是通过再发命令回来读运行时状态实现的用户点继续agent 恢复线程执行一句话概括断点 把一个内存页设成不可读让程序在序列点主动踩雷用 SIGSEGV 把控制权交给调试器。四、断点 vs 单步两种机制的区别这两者容易混其实机制不同断点Breakpoint——精确定位只在你设的那个具体位置生效。实现上不一定全靠触发页扫描agent 知道具体是哪个方法哪个 IL 偏移可以精确地在该 native 地址处打点。命中范围明确。单步Single Step——全局开关“执行到下一个序列点就停”。做法是把 single-step 触发页设成不可读这样下一个碰到的序列点就会触发 SIGSEGV。停下后 agent 判断Step Over步过: 停在同一栈帧的下一个序列点遇到调用不进去 Step Into步入: 进入被调用方法的第一个序列点 Step Out步出: 在当前方法返回后的序列点停下agent 靠对比栈深度和序列点信息来实现这三种语义——单步触发只是提供了到下个序列点停一下的能力具体停不停由 agent 逻辑判断不满足就悄悄恢复继续跑。五、几个必须处理的现实问题1. 断点设在还没编译的方法上怎么办JIT 是懒编译方法第一次被调用才编译。你在一个还没跑到的方法上打断点时agent 先记录待定断点pending“等这个方法被 JIT 编译时再把断点真正落到它的序列点上。这就是为什么有时断点显示暂未绑定”跑到附近才变实心。2. 条件断点if (i 100) break这种条件不是在运行时原生判断的。通常是每次命中都停下 → agent 求值条件 → 不满足就静默继续。所以条件断点开销比普通断点大命中频繁时会明显拖慢。3. 多线程挂起策略命中断点时是只停当前线程还是停全部Soft Debugger 支持策略配置。停全部才能看到一致的全局快照但要小心持有锁的线程被停住导致的死锁式卡顿。4. 为什么调试时性能下降带调试信息编译会在每个序列点插入触发页读取指令JIT 也会关闭部分优化否则变量被优化掉、代码重排源码行对不上。这就是 debug 模式比 release 慢的一部分原因。六、整条链路串起来IDE: 在 Foo.cs:42 打断点 │ wire protocol ▼ Agent: 查 debug info → 定位到 方法Foo / IL offset 0x1A / 一个序列点 │ ├─ 方法已编译 → 在对应 native 位置激活断点 └─ 方法未编译 → 记为 pending等 JIT 编译时补上 │ ▼ 程序运行到序列点 → 读触发页 → SIGSEGV │ ▼ Mono 信号处理器识别是调试事件非真崩溃 │ ▼ Agent挂起线程 → 反查当前源码位置 → 发命中事件给 IDE │ ▼ IDE显示调用栈/变量继续发命令回来读运行时状态 │ ▼ 用户点继续 → Agent 恢复线程 → 继续跑核心思想总结用 debug info 把「源码行」映射到「序列点」JIT 在序列点插入对特殊内存页的读取需要停下时就把该页mprotect成不可访问让程序主动触发 SIGSEGVMono 的信号处理器把这个假崩溃转成调试事件挂起线程并交给内嵌的 debugger agentagent 再通过 wire protocol 与 IDE 交互。整个过程不依赖任何 OS 级调试设施因此跨平台、且能与 JIT 协作。