Miri 项目中多种子模式的技术实现探讨

在 Rust 的 Miri 解释器项目中，目前存在两种独立实现的多种子（many-seeds）模式运行方式，分别位于直接运行（./miri run）和通过 cargo 运行（cargo miri）的路径下。这两种实现存在功能重复的问题，且前者支持并发执行而后者不支持。

从技术架构角度看，更合理的解决方案是将多种子模式直接集成到 Miri 的驱动层。这可以通过引入类似 -Zmiri-many-seeds 的编译器标志来实现。目前存在两种可行的技术路径：

第一种方案是在单个 rustc 驱动会话中创建多个解释器实例。由于所有相关状态都应封装在解释器实例内部，这种方式能够保证执行的独立性。理论上这些实例甚至可以共享查询缓存，但此方案的局限性在于执行只能是顺序的，除非能够利用 rustc 的并行编译功能。

第二种方案则是在 Miri 二进制程序中创建多个 rustc 驱动会话，每个会话运行在独立的线程中。虽然 rustc 驱动基础设施主要设计为单进程单实例运行，但技术上是可行的，因为其仅依赖线程本地存储（TLS）而非真正的全局状态。

值得注意的是，Miri 目前使用了一些静态变量来避免重复错误信息的输出。在实现多实例并行运行时，需要仔细审核这些静态变量的使用场景，确保它们在新架构下的合理性。

从实现难度和稳定性考虑，直接利用 rustc 的并行逻辑可能是更优选择。虽然并行 rustc 仍存在一些已知问题，但初步实践表明这种方案能够正常工作。这种集成方式不仅能消除代码重复，还能统一并发行为，为 Miri 的多种子测试提供更一致和可靠的执行环境。