Madeira中JIT如何完整跑起来从StikDebug附加到CS_DEBUGGED标志的完整指南【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu Wine DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/MadeiraMadeira是一个让 iPhone 通过 FEX-Emu Wine 运行 x86-64 Windows PC 游戏的开源项目。由于 iOS 默认禁止应用执行自生成的代码Madeira 必须借助StikDebug调试器附加进程让内核置位CS_DEBUGGED 标志JIT 才能被允许执行。本文带你完整走一遍这条 JIT 生命周期链路拉起调试器 → 轮询 CS_DEBUGGED → 分配 JIT 内存池 → 分离调试器 → 游戏稳定运行。为什么 JIT 需要调试器身份证iOS 的 W^X 策略写入和可执行不可兼得默认会拒绝应用执行自己写出的机器码。而 Madeira 的整个加速核心——FEX-Emu 把 x86-64 指令实时翻译成 ARM64 机器码——恰恰就是典型的 JIT 场景。系统里存在一条特殊通道当进程被调试器附加traced时内核会在进程状态中置位 CS_DEBUGGED 标志0x10000000允许该进程执行 JIT 区域。这就是 StikDebug 存在的意义——它不是调试工具而是 JIT 的身份证。你可以在 EntitlementChecker.swift 中看到作者对这个机制的说明allow-jit权限是 macOS 专属、iOS 永远拿不到真正起作用的是被 trace 状态下的 CS_DEBUGGED 标志。 简单理解iOS 说不给你 JIT 权限Madeira 说那我把你正在被调试这个状态当成 JIT 权限用。第一步用 URL Scheme 拉起 StikDebug整个流程的入口是 StikJITHelper.swift。它做了三件事准备脚本项目内置了一份 JIT 辅助脚本 madeira-jit.js负责在调试器侧处理断点协议BRK #0xf00d、转发故障信号等。脚本以 Base64 内嵌在代码中开发时也可以从 bundle 资源加载构造 URL 并跳转拼接stikjit://enable-jit?bundle-id...script-data...并调用系统打开StikDebug 收到后就会附加到 Madeira 进程并运行脚本进入轮询跳转成功后调用pollForJIT等待标志位变化。核心入口逻辑见 StikJITHelper.swift 的enableJIT方法static func enableJIT(completion: escaping (Bool) - Void) { // 构造 stikjit://enable-jit?...script-database64脚本 UIApplication.shared.open(url) { success in if success { pollForJIT(completion: completion) } } }第二步轮询 CS_DEBUGGED确认调试器已就位附加完成后内核会置位 CS_DEBUGGED。Madeira 用一个小定时器每 0.5 秒轮询一次底层调用 JITAllocator.c 中的jit_check_debugged()通过csops(getpid(), CS_OPS_STATUS, ...)系统调用读取进程状态检查flags CS_DEBUGGED是否非零一旦检测到置位日志会打印JIT enabled! (CS_DEBUGGED set)轮询结束回调成功。见 StikJITHelper.swift 的pollForJITTimer.scheduledTimer(withTimeInterval: 0.5, repeats: true) { timer in if jit_check_debugged() { timer.invalidate() LogStore.shared.log(JIT enabled! (CS_DEBUGGED set), level: .success) completion(true) } }这个 CS_DEBUGGED 检查贯穿全生命周期——之后每次启动游戏前ContentView.swift 的runWineFullSequence都会再确认一次未置位就直接提示先启用 JIT。第三步分配 JIT 内存池RX RW 双映射确认 CS_DEBUGGED 之后allocatePoolStikJITHelper.swift负责向调试器要地RX 可执行池通过 JITAllocator.c 中的jit26_prepare_region触发BRK #0xf00d自定义断点协议x161 表示请分配 len 大小的可执行页由 StikDebug 侧完成分配RW 写映射拿到 RX 地址后用vm_remap建立同一物理内存的读写别名——FEX 往 RW 侧写代码CPU 从 RX 侧执行地址约束这是这段代码最有故事的部分。池子必须落在 ≥0x119000000的高地址低地址会触发 FEX 的编码 bug不能落进 64GB 的 guest 窗口也不能吞掉0x140000000的可执行窗口。代码里会先做一轮空洞普查必要时把池子缩小到能放下的最大尺寸。第四步分离调试器游戏开始自由奔跑JIT 池就位后并不是让 StikDebug 常驻——作者发现调试器每 60 秒就会烧掉约 48 秒 CPU且它离场无论是退出还是被杀都会造成一次约 54 秒的全局卡顿。因此策略是**在我们选定的时刻一次性付掉这笔成本**detachDebugger()StikJITHelper.swift通过BRK #0xf00dx160即 CMD_DETACH让脚本发出分离指令并设置MADEIRA_DETACHED环境变量通知进程内等待者在 ContentView.swift 的启动序列中early detachml524会在 VM 地址映射还很小的时候就分离调试器随后才启动 wineserver 和 Wine。分离后已编译的代码块依然可执行只有新的 BRK 编译请求会失败所以分离前已跑完 PE 加载、音频初始化等重编译阶段是关键。生命周期一图流阶段触发点关键动作① 拉起调试器enableJITstikjit://URL Scheme 打开 StikDebug携带 Base64 脚本② 确认就位pollForJIT每 0.5s 检查csops返回的 CS_DEBUGGED 位③ 分配 JIT 池allocatePoolBRK #0xf00d 协议向调试器要 RX 页 vm_remap建 RW 别名④ 分离调试器detachDebuggerCMD_DETACH设置MADEIRA_DETACHED一次性付清卡顿成本⑤ 稳定运行Wine 启动后已编译块照常执行FEX 在 RX/RW 双映射池上跑满性能小结一条标志位背后的完整设计回头看Madeira 的 JIT 生命周期其实是一次漂亮的借势CS_DEBUGGED 是钥匙把被调试状态转化为 JIT 执行许可绕开 iOS 拿不到的allow-jit权限URL Scheme 是入口应用之间无需用户手动操作一行跳转完成调试器附加 脚本注入BRK #0xf00d 是通信协议自造断点指令在宿主与调试器之间传递分配内存 / 分离等指令early detach 是性能优化把调试器的固定开销从游戏全程压缩成启动时一次。如果你想动手看细节建议从这三个文件入手StikJITHelper.swift生命周期编排、JITAllocator.cCS_DEBUGGED 检查与 BRK 协议、madeira-jit.js调试器侧脚本处理断点与信号转发。【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu Wine DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/2 17:57:24 · 阅读 1.2k Madeira中JIT如何完整跑起来：从StikDebug附加到CS_DEBUGGED标志的完整指南
Madeira中JIT如何完整跑起来从StikDebug附加到CS_DEBUGGED标志的完整指南【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu Wine DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/MadeiraMadeira是一个让 iPhone 通过 FEX-Emu Wine 运行 x86-64 Windows PC 游戏的开源项目。由于 iOS 默认禁止应用执行自生成的代码Madeira 必须借助StikDebug调试器附加进程让内核置位CS_DEBUGGED 标志JIT 才能被允许执行。本文带你完整走一遍这条 JIT 生命周期链路拉起调试器 → 轮询 CS_DEBUGGED → 分配 JIT 内存池 → 分离调试器 → 游戏稳定运行。为什么 JIT 需要调试器身份证iOS 的 W^X 策略写入和可执行不可兼得默认会拒绝应用执行自己写出的机器码。而 Madeira 的整个加速核心——FEX-Emu 把 x86-64 指令实时翻译成 ARM64 机器码——恰恰就是典型的 JIT 场景。系统里存在一条特殊通道当进程被调试器附加traced时内核会在进程状态中置位 CS_DEBUGGED 标志0x10000000允许该进程执行 JIT 区域。这就是 StikDebug 存在的意义——它不是调试工具而是 JIT 的身份证。你可以在 EntitlementChecker.swift 中看到作者对这个机制的说明allow-jit权限是 macOS 专属、iOS 永远拿不到真正起作用的是被 trace 状态下的 CS_DEBUGGED 标志。 简单理解iOS 说不给你 JIT 权限Madeira 说那我把你正在被调试这个状态当成 JIT 权限用。第一步用 URL Scheme 拉起 StikDebug整个流程的入口是 StikJITHelper.swift。它做了三件事准备脚本项目内置了一份 JIT 辅助脚本 madeira-jit.js负责在调试器侧处理断点协议BRK #0xf00d、转发故障信号等。脚本以 Base64 内嵌在代码中开发时也可以从 bundle 资源加载构造 URL 并跳转拼接stikjit://enable-jit?bundle-id...script-data...并调用系统打开StikDebug 收到后就会附加到 Madeira 进程并运行脚本进入轮询跳转成功后调用pollForJIT等待标志位变化。核心入口逻辑见 StikJITHelper.swift 的enableJIT方法static func enableJIT(completion: escaping (Bool) - Void) { // 构造 stikjit://enable-jit?...script-database64脚本 UIApplication.shared.open(url) { success in if success { pollForJIT(completion: completion) } } }第二步轮询 CS_DEBUGGED确认调试器已就位附加完成后内核会置位 CS_DEBUGGED。Madeira 用一个小定时器每 0.5 秒轮询一次底层调用 JITAllocator.c 中的jit_check_debugged()通过csops(getpid(), CS_OPS_STATUS, ...)系统调用读取进程状态检查flags CS_DEBUGGED是否非零一旦检测到置位日志会打印JIT enabled! (CS_DEBUGGED set)轮询结束回调成功。见 StikJITHelper.swift 的pollForJITTimer.scheduledTimer(withTimeInterval: 0.5, repeats: true) { timer in if jit_check_debugged() { timer.invalidate() LogStore.shared.log(JIT enabled! (CS_DEBUGGED set), level: .success) completion(true) } }这个 CS_DEBUGGED 检查贯穿全生命周期——之后每次启动游戏前ContentView.swift 的runWineFullSequence都会再确认一次未置位就直接提示先启用 JIT。第三步分配 JIT 内存池RX RW 双映射确认 CS_DEBUGGED 之后allocatePoolStikJITHelper.swift负责向调试器要地RX 可执行池通过 JITAllocator.c 中的jit26_prepare_region触发BRK #0xf00d自定义断点协议x161 表示请分配 len 大小的可执行页由 StikDebug 侧完成分配RW 写映射拿到 RX 地址后用vm_remap建立同一物理内存的读写别名——FEX 往 RW 侧写代码CPU 从 RX 侧执行地址约束这是这段代码最有故事的部分。池子必须落在 ≥0x119000000的高地址低地址会触发 FEX 的编码 bug不能落进 64GB 的 guest 窗口也不能吞掉0x140000000的可执行窗口。代码里会先做一轮空洞普查必要时把池子缩小到能放下的最大尺寸。第四步分离调试器游戏开始自由奔跑JIT 池就位后并不是让 StikDebug 常驻——作者发现调试器每 60 秒就会烧掉约 48 秒 CPU且它离场无论是退出还是被杀都会造成一次约 54 秒的全局卡顿。因此策略是**在我们选定的时刻一次性付掉这笔成本**detachDebugger()StikJITHelper.swift通过BRK #0xf00dx160即 CMD_DETACH让脚本发出分离指令并设置MADEIRA_DETACHED环境变量通知进程内等待者在 ContentView.swift 的启动序列中early detachml524会在 VM 地址映射还很小的时候就分离调试器随后才启动 wineserver 和 Wine。分离后已编译的代码块依然可执行只有新的 BRK 编译请求会失败所以分离前已跑完 PE 加载、音频初始化等重编译阶段是关键。生命周期一图流阶段触发点关键动作① 拉起调试器enableJITstikjit://URL Scheme 打开 StikDebug携带 Base64 脚本② 确认就位pollForJIT每 0.5s 检查csops返回的 CS_DEBUGGED 位③ 分配 JIT 池allocatePoolBRK #0xf00d 协议向调试器要 RX 页 vm_remap建 RW 别名④ 分离调试器detachDebuggerCMD_DETACH设置MADEIRA_DETACHED一次性付清卡顿成本⑤ 稳定运行Wine 启动后已编译块照常执行FEX 在 RX/RW 双映射池上跑满性能小结一条标志位背后的完整设计回头看Madeira 的 JIT 生命周期其实是一次漂亮的借势CS_DEBUGGED 是钥匙把被调试状态转化为 JIT 执行许可绕开 iOS 拿不到的allow-jit权限URL Scheme 是入口应用之间无需用户手动操作一行跳转完成调试器附加 脚本注入BRK #0xf00d 是通信协议自造断点指令在宿主与调试器之间传递分配内存 / 分离等指令early detach 是性能优化把调试器的固定开销从游戏全程压缩成启动时一次。如果你想动手看细节建议从这三个文件入手StikJITHelper.swift生命周期编排、JITAllocator.cCS_DEBUGGED 检查与 BRK 协议、madeira-jit.js调试器侧脚本处理断点与信号转发。【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu Wine DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考