ReadyToRun 平台原生封装Mach-O设计解析.NET 11 如何让 R2R 跨出 PE 格式【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读ReadyToRunR2R是 .NET 运行时用来分发已预编译原生代码的格式程序集中同时携带 IL 与机器码加载时无需 JIT 即可直接执行热点方法。本文基于 dotnet/runtime 仓库的 ReadyToRun Platform Native Envelope 设计文档剖析 .NET 11 计划引入的一项重大演进——为 R2R 增加PE 之外的平台原生封装格式以 Mach-OmacOS为首个目标。读完本文你将理解crossgen2 如何产出 Mach-O 对象文件、Mach-O 中如何模拟 PE 的 Section/RVA/重定位语义、运行时如何通过新的 host 回调消费平台原生 R2R 镜像以及对应的 R2R 头标志位与版本演进R2R Version 17.1在仓库源码中的落点。背景为什么 R2R 需要一个平台原生封装从 .NET 运行时诞生到 .NET 10ReadyToRun 在所有平台上都使用Windows PE 格式作为原生封装native envelope。也就是说macOS / Linux 等非 Windows 平台加载 R2R 镜像时实际上是在加载一个 PE 文件并由 .NET 自己的加载器完成 PE 所需的 fixup 与代码激活而不是借助平台操作系统加载器。正如 ReadyToRun 总览 所述这种全平台 PE方案的代价是无法利用各平台原生的可执行/共享库加载机制如 macOS 的dlopen、Linux 的 ELF loader。R2R 的设计目标是让托管代码具备接近非托管代码的部署特性——格式清晰、可直接执行、遵循版本规则即可独立演进——而 PE 封装在非 Windows 平台上始终隔着一层自加载的间接性。因此readytorun-platform-native-envelope.md 提出了 .NET 11 的计划开始支持 PE 之外的封装格式Mach-O 是第一个目标。需要强调的是这是文档中明确标注的tentative high-level design暂定高层设计随着实现推进文档本身以及 readytorun-overview.md 与 readytorun-format.md 都会被同步更新。首批支持范围.NET 11设计文档明确限定了首个版本的边界避免一上来就铺开所有场景仅支持 Composite R2R复合 R2R多个 IL 程序集被编译进同一个镜像而不是每个程序集单独一份 R2R 镜像由crossgen2产出 Mach-O 对象文件object file而非最终的可执行文件运行时使用Mach-O 共享库形态的 Composite R2R 镜像把对象文件链接成共享库dylib的工作由 SDK/构建步骤负责不在本设计文档的讨论范围内。crossgen2产出 Mach-O 对象文件Mach-O 支持仅在目标 OS 为 macOS时、且为Composite ReadyToRun场景下启用并通过一个新的crossgen2命令行开关显式选择--obj-format macho在仓库源码中该开关以及别名-f定义于 Crossgen2RootCommand.cs合法取值枚举为pe、macho、wasm默认值为pe--obj-format pe|macho|wasm 默认 pe这印证了设计文档的判断PE 仍是默认封装Mach-O 是显式 opt-in 的新能力wasm对应 WebAssembly 场景的 WebCIL 输出。产出物与标志位crossgen2 --obj-format macho产出一个Mach-O 对象文件作为 Composite R2R 镜像并同时做三件事导出RTR_HEADER符号指向READYTORUN_HEADER。导出符号名默认为RTR_HEADER可通过--rtr-header-symbol-name覆盖见下文将每个输入 IL 程序集标记为component R2R assembly设置READYTORUN_FLAG_COMPONENT给每个输入 IL 程序集设置一个新标志表示其所属的 Composite 镜像采用平台原生格式READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE。crossgen2本身不产出最终的共享库。SDK / 构建侧的链接步骤必须把RTR_HEADER导出或通过--rtr-header-symbol-name指定的自定义名保留在最终的dylib中否则运行时将无法定位 R2R 头。在源码层面上述标志位均已落定在 readytorun.h 的ReadyToRunFlag枚举中READYTORUN_FLAG_COMPONENT 0x00000020, // 描述 Composite R2R 中某个 component assembly 的头 READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE 0x00000100, // 所属 Composite 可执行文件采用平台原生格式该头文件的版本注释还明确指出R2R Version 17.1 引入了READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE标志用于标识OwnerCompositeExecutable指向的 R2R 镜像为平台原生格式readytorun.h。RTR_HEADER导出符号的生成逻辑可以在 ReadyToRunObjectWriter.cs 中看到在 Composite 构建模式下若配置了ReadyToRunHeaderSymbolName则使用它否则使用默认名RTR_HEADER随后通过AddExportedSymbol注册导出string configuredSymbolName _nodeFactory.CompositeImageSettings?.ReadyToRunHeaderSymbolName; string symbolName string.IsNullOrWhiteSpace(configuredSymbolName) ? RTR_HEADER : configuredSymbolName; objectWriter.AddExportedSymbol(symbolName);自定义 RTR_HEADER 符号名crossgen2 --rtr-header-symbol-name name用于覆盖READYTORUN_HEADER的导出符号名。设计文档给出了这一选项的典型用途自定义 host 直接静态链接多个 R2R 镜像而不是通过dlopen等动态加载此时每个镜像需要不同的导出符号名以避免符号冲突相应地运行时或 host 在定位头时必须使用匹配的自定义名称。该选项同样注册于 Crossgen2RootCommand.cs。Mach-O Emitter 设计决策R2R 格式中有若干概念是 Mach-O 不原生支持的需要在 Mach-O 发射器emitter中模拟。设计文档从三个维度给出了取舍。Section 映射从__TEXT,__text移出的数据预编译托管代码移入__TEXT,__managedcode。原因__TEXT,__text会被链接器特殊对待而__TEXT,__managedcode与 NativeAOT 的约定一致可复用既有工具链行为只读数据——跳转表jump tables、CLR 元数据、Win32 资源、托管 unwind 信息、GC 信息以及R2R headers 本身——移入__TEXT,__const。保持与 PE 封装对应位置一致的数据读写数据如 fixup 表__DATA,__data导入 thunkimport thunks__TEXT,__text。重定位RelocationsMach-O 对符号范围的表示与其他平台不同。Apple 链接器在多个符号定义于同一位置时存在问题与此同时 Mach 格式原生支持subtractor 重定位用两个符号之差表示距离。因此符号范围的起点用范围的起始符号表示符号范围的大小表示为结束符号位置 − 起始符号位置 结束符号大小。基础符号Base Symbol与 RVAR2R 格式与 PE 格式一样重度依赖写入镜像的 RVA相对虚拟地址——运行时把这些 RVA 加上镜像的基础符号base symbol即得到实际地址。COFF 对象格式原生支持这一概念PE 格式也在 PE 头中使用了它但其他格式并不原生支持。Mach-O 的应对方式是借助 Apple 链接器提供的基础符号。该符号取决于输出类型一般形式为__mh_output_header对 dylib基础符号是__mh_dylib_header该符号位于dlinfo与dladdr返回的基地址处它指向 Mach header可用 header 反推镜像大小从而限定 R2R 数据的读取边界。因此 R2R 的 Mach-O 模拟方案非常直接对象写入器使用的基础符号就是__mh_dylib_header发射距基础符号的距离时使用subtractor 重定位表示符号位置 −__mh_dylib_header位置。源码佐证在 ReadyToRunObjectWriter.cs 中CreateMachObjectWriter创建MachObjectWriter时显式传入baseSymbolName: __mh_dylib_headerprivate MachObjectWriter CreateMachObjectWriter() { return new MachObjectWriter(_nodeFactory, ObjectWritingOptions.None, _outputInfoBuilder, baseSymbolName: __mh_dylib_header); }与 PE 对象写入器CreatePEObjectWriter相比Mach-O 写入器不再依赖输入 PE 的 COFF TimeDateStamp也无需处理自定义 Section 对齐进一步印证平台原生封装是独立于 PE 心智模型的一套发射路径。运行时消费平台原生 R2R 镜像运行时需要在程序集加载阶段感知并处理平台原生 R2R 镜像。设计文档给出了加载决策流程加载 IL 程序集判断其是否为 R2R 程序集若不是component R2R 程序集 → 走既有 R2R 加载逻辑该场景暂不支持平台原生格式若是 component R2R 程序集且设置了新标志READYTORUN_FLAG_PLATFORM_NATIVE_IMAGEa. 读取OwnerCompositeExecutable值b. 以 component assembly 路径与 owner composite 名称调用 host 回调c. 回调成功 → 拿到 CompositeREADYTORUN_HEADER指针用于原生方法查找 / fixupd. 回调失败 → 回退到 IL/JIT 路径若未设置平台原生标志 → 走既有 R2R 加载逻辑PE 程序集查找与加载。注意第 3.d 步平台原生路径的失败是软失败——运行时优雅降级为 JIT 编译而不是拒绝加载程序集。这对部署韧性很关键即使 dylib 缺失或加载失败应用仍可通过 IL 运行只是失去预编译性能收益。Host 回调get_native_code_data加载流程的关键是新引入的 host 回调。设计文档中host_runtime_contract 将更新以新增获取原生代码信息的回调并给出了两个结构与一个函数原型struct native_code_context { size_t size; // size of this struct const char* assembly_path; // component assembly path const char* owner_composite_name; // name from component R2R header }; struct native_code_data { size_t size; // size of this struct void* r2r_header_ptr; // ReadyToRun header size_t image_size; // size of the image void* image_base; // base address where the image was loaded }; bool get_native_code_data( const struct native_code_context* context, /*out*/ struct native_code_data* data );该回调的设计意图是把实际的加载动作完全留给 hosthost 可以dlopen一个共享库也可以使用静态链接进 host 自身的东西同时缓存策略也由 host 负责回调注释明确Any callbacks set on this contract are expected to be valid for the lifetime of the process。在仓库当前代码中该契约已落地于 host_runtime_contract.h两个结构体实际命名为host_runtime_contract_native_code_context与host_runtime_contract_native_code_data比设计文档中的native_code_context/native_code_data多了host_runtime_contract_前缀与头文件内其他类型保持一致字段与设计文档一一对应assembly_path、owner_composite_name、r2r_header_ptr、image_size、image_base每个结构体首字段均为size用于版本化演进回调以函数指针形式挂入host_runtime_contract结构体// Get native code data for the assembly specified by the supplied context bool(HOST_CONTRACT_CALLTYPE* get_native_code_data)( const struct host_runtime_contract_native_code_context* context, /*out*/ struct host_runtime_contract_native_code_data* data);从该头文件还可以看到整个 host 契约的全貌除get_native_code_data外还包括get_runtime_property读运行时属性、bundle_probe探测 app bundle、pinvoke_overrideP/Invoke 覆盖、external_assembly_probe探测外部程序集等既有回调。get_native_code_data与external_assembly_probe在形态上类似都涉及host 提供代码/数据段指针但前者额外携带 owner composite 名称与镜像基址/大小信息专门服务于平台原生 R2R 的头部定位。头格式与版本演进落点READYTORUN_HEADER的结构定义于 readytorun.hstruct READYTORUN_HEADER { DWORD Signature; // READYTORUN_SIGNATURE USHORT MajorVersion; // READYTORUN_VERSION_XXX USHORT MinorVersion; READYTORUN_CORE_HEADER CoreHeader; };其中READYTORUN_CORE_HEADER以Flags承载上述各READYTORUN_FLAG_*。与本设计直接相关的两个 Section 类型也定义在同一文件readytorun.hComponentAssemblies 115V4.1 加入列出 Composite 镜像中的 component assembliesOwnerCompositeExecutable 116V4.1 加入运行时第 3.a 步读取的正是这个 Section用于定位拥有该 component 的 Composite 镜像。READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE的加入被记录为R2R Version 17.1readytorun.h这是 R2R 头版本演化中一次典型的非破坏性扩展旧运行时看到未知标志时仍可按既有路径处理PE 查找/加载或 IL 回退新运行时则能据此切换到平台原生消费路径。版本化设计是 R2R 兼容性保证的核心——如 readytorun-overview.md 所述格式中放入的每一项都是未来所有运行时都必须支持的责任因此设计趋于极简平台原生封装同样遵循这一原则能复用的 Section 布局与标志位语义尽量复用只新增必要的最小增量一个标志、一个回调、一个基础符号约定。总结与展望综合设计文档与仓库现状可以梳理出 .NET 11 ReadyToRun 平台原生封装的完整脉络层面关键决策仓库落点编译--obj-format macho默认pe仅 Composite R2R macOSCrossgen2RootCommand.cs符号导出RTR_HEADER可经--rtr-header-symbol-name覆盖指向READYTORUN_HEADERReadyToRunObjectWriter.cs标志位每个 component 设置READYTORUN_FLAG_COMPONENTREADYTORUN_FLAG_PLATFORM_NATIVE_IMAGER2R V17.1readytorun.h基础符号对象写入器使用__mh_dylib_headersubtractor 重定位模拟 RVAReadyToRunObjectWriter.csSection托管代码入__TEXT,__managedcode只读数据入__TEXT,__constfixup 表留__DATA,__data设计文档 NativeAOT 对齐约定运行时按标志位分流OwnerCompositeExecutable→ host 回调 → R2R 头失败回退 IL/JIThost_runtime_contract.h需要留意的是readytorun-platform-native-envelope.md 本身仍是一份进行中的设计文档其明示tentative high-level design并承诺实现过程中会持续更新本文档及总览/格式文档。仓库中已可见的标志位、CLI 选项与 host 契约回调证明该方向已开始落地但 dylib 链接步骤、运行时消费逻辑的最终形态如第 2 步非 component 不支持平台原生、第 3.d 步回退细节仍以文档演进与后续实现为准。对 R2R 格式整体结构感兴趣的读者可进一步阅读 readytorun-overview.md动机、版本气泡、版本韧性代码生成与 readytorun-format.mdSection 与 Fixup 的详细布局。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ReadyToRun 平台原生封装Mach-O设计解析.NET 11 如何让 R2R 跨出 PE 格式【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读ReadyToRunR2R是 .NET 运行时用来分发已预编译原生代码的格式程序集中同时携带 IL 与机器码加载时无需 JIT 即可直接执行热点方法。本文基于 dotnet/runtime 仓库的 ReadyToRun Platform Native Envelope 设计文档剖析 .NET 11 计划引入的一项重大演进——为 R2R 增加PE 之外的平台原生封装格式以 Mach-OmacOS为首个目标。读完本文你将理解crossgen2 如何产出 Mach-O 对象文件、Mach-O 中如何模拟 PE 的 Section/RVA/重定位语义、运行时如何通过新的 host 回调消费平台原生 R2R 镜像以及对应的 R2R 头标志位与版本演进R2R Version 17.1在仓库源码中的落点。背景为什么 R2R 需要一个平台原生封装从 .NET 运行时诞生到 .NET 10ReadyToRun 在所有平台上都使用Windows PE 格式作为原生封装native envelope。也就是说macOS / Linux 等非 Windows 平台加载 R2R 镜像时实际上是在加载一个 PE 文件并由 .NET 自己的加载器完成 PE 所需的 fixup 与代码激活而不是借助平台操作系统加载器。正如 ReadyToRun 总览 所述这种全平台 PE方案的代价是无法利用各平台原生的可执行/共享库加载机制如 macOS 的dlopen、Linux 的 ELF loader。R2R 的设计目标是让托管代码具备接近非托管代码的部署特性——格式清晰、可直接执行、遵循版本规则即可独立演进——而 PE 封装在非 Windows 平台上始终隔着一层自加载的间接性。因此readytorun-platform-native-envelope.md 提出了 .NET 11 的计划开始支持 PE 之外的封装格式Mach-O 是第一个目标。需要强调的是这是文档中明确标注的tentative high-level design暂定高层设计随着实现推进文档本身以及 readytorun-overview.md 与 readytorun-format.md 都会被同步更新。首批支持范围.NET 11设计文档明确限定了首个版本的边界避免一上来就铺开所有场景仅支持 Composite R2R复合 R2R多个 IL 程序集被编译进同一个镜像而不是每个程序集单独一份 R2R 镜像由crossgen2产出 Mach-O 对象文件object file而非最终的可执行文件运行时使用Mach-O 共享库形态的 Composite R2R 镜像把对象文件链接成共享库dylib的工作由 SDK/构建步骤负责不在本设计文档的讨论范围内。crossgen2产出 Mach-O 对象文件Mach-O 支持仅在目标 OS 为 macOS时、且为Composite ReadyToRun场景下启用并通过一个新的crossgen2命令行开关显式选择--obj-format macho在仓库源码中该开关以及别名-f定义于 Crossgen2RootCommand.cs合法取值枚举为pe、macho、wasm默认值为pe--obj-format pe|macho|wasm 默认 pe这印证了设计文档的判断PE 仍是默认封装Mach-O 是显式 opt-in 的新能力wasm对应 WebAssembly 场景的 WebCIL 输出。产出物与标志位crossgen2 --obj-format macho产出一个Mach-O 对象文件作为 Composite R2R 镜像并同时做三件事导出RTR_HEADER符号指向READYTORUN_HEADER。导出符号名默认为RTR_HEADER可通过--rtr-header-symbol-name覆盖见下文将每个输入 IL 程序集标记为component R2R assembly设置READYTORUN_FLAG_COMPONENT给每个输入 IL 程序集设置一个新标志表示其所属的 Composite 镜像采用平台原生格式READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE。crossgen2本身不产出最终的共享库。SDK / 构建侧的链接步骤必须把RTR_HEADER导出或通过--rtr-header-symbol-name指定的自定义名保留在最终的dylib中否则运行时将无法定位 R2R 头。在源码层面上述标志位均已落定在 readytorun.h 的ReadyToRunFlag枚举中READYTORUN_FLAG_COMPONENT 0x00000020, // 描述 Composite R2R 中某个 component assembly 的头 READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE 0x00000100, // 所属 Composite 可执行文件采用平台原生格式该头文件的版本注释还明确指出R2R Version 17.1 引入了READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE标志用于标识OwnerCompositeExecutable指向的 R2R 镜像为平台原生格式readytorun.h。RTR_HEADER导出符号的生成逻辑可以在 ReadyToRunObjectWriter.cs 中看到在 Composite 构建模式下若配置了ReadyToRunHeaderSymbolName则使用它否则使用默认名RTR_HEADER随后通过AddExportedSymbol注册导出string configuredSymbolName _nodeFactory.CompositeImageSettings?.ReadyToRunHeaderSymbolName; string symbolName string.IsNullOrWhiteSpace(configuredSymbolName) ? RTR_HEADER : configuredSymbolName; objectWriter.AddExportedSymbol(symbolName);自定义 RTR_HEADER 符号名crossgen2 --rtr-header-symbol-name name用于覆盖READYTORUN_HEADER的导出符号名。设计文档给出了这一选项的典型用途自定义 host 直接静态链接多个 R2R 镜像而不是通过dlopen等动态加载此时每个镜像需要不同的导出符号名以避免符号冲突相应地运行时或 host 在定位头时必须使用匹配的自定义名称。该选项同样注册于 Crossgen2RootCommand.cs。Mach-O Emitter 设计决策R2R 格式中有若干概念是 Mach-O 不原生支持的需要在 Mach-O 发射器emitter中模拟。设计文档从三个维度给出了取舍。Section 映射从__TEXT,__text移出的数据预编译托管代码移入__TEXT,__managedcode。原因__TEXT,__text会被链接器特殊对待而__TEXT,__managedcode与 NativeAOT 的约定一致可复用既有工具链行为只读数据——跳转表jump tables、CLR 元数据、Win32 资源、托管 unwind 信息、GC 信息以及R2R headers 本身——移入__TEXT,__const。保持与 PE 封装对应位置一致的数据读写数据如 fixup 表__DATA,__data导入 thunkimport thunks__TEXT,__text。重定位RelocationsMach-O 对符号范围的表示与其他平台不同。Apple 链接器在多个符号定义于同一位置时存在问题与此同时 Mach 格式原生支持subtractor 重定位用两个符号之差表示距离。因此符号范围的起点用范围的起始符号表示符号范围的大小表示为结束符号位置 − 起始符号位置 结束符号大小。基础符号Base Symbol与 RVAR2R 格式与 PE 格式一样重度依赖写入镜像的 RVA相对虚拟地址——运行时把这些 RVA 加上镜像的基础符号base symbol即得到实际地址。COFF 对象格式原生支持这一概念PE 格式也在 PE 头中使用了它但其他格式并不原生支持。Mach-O 的应对方式是借助 Apple 链接器提供的基础符号。该符号取决于输出类型一般形式为__mh_output_header对 dylib基础符号是__mh_dylib_header该符号位于dlinfo与dladdr返回的基地址处它指向 Mach header可用 header 反推镜像大小从而限定 R2R 数据的读取边界。因此 R2R 的 Mach-O 模拟方案非常直接对象写入器使用的基础符号就是__mh_dylib_header发射距基础符号的距离时使用subtractor 重定位表示符号位置 −__mh_dylib_header位置。源码佐证在 ReadyToRunObjectWriter.cs 中CreateMachObjectWriter创建MachObjectWriter时显式传入baseSymbolName: __mh_dylib_headerprivate MachObjectWriter CreateMachObjectWriter() { return new MachObjectWriter(_nodeFactory, ObjectWritingOptions.None, _outputInfoBuilder, baseSymbolName: __mh_dylib_header); }与 PE 对象写入器CreatePEObjectWriter相比Mach-O 写入器不再依赖输入 PE 的 COFF TimeDateStamp也无需处理自定义 Section 对齐进一步印证平台原生封装是独立于 PE 心智模型的一套发射路径。运行时消费平台原生 R2R 镜像运行时需要在程序集加载阶段感知并处理平台原生 R2R 镜像。设计文档给出了加载决策流程加载 IL 程序集判断其是否为 R2R 程序集若不是component R2R 程序集 → 走既有 R2R 加载逻辑该场景暂不支持平台原生格式若是 component R2R 程序集且设置了新标志READYTORUN_FLAG_PLATFORM_NATIVE_IMAGEa. 读取OwnerCompositeExecutable值b. 以 component assembly 路径与 owner composite 名称调用 host 回调c. 回调成功 → 拿到 CompositeREADYTORUN_HEADER指针用于原生方法查找 / fixupd. 回调失败 → 回退到 IL/JIT 路径若未设置平台原生标志 → 走既有 R2R 加载逻辑PE 程序集查找与加载。注意第 3.d 步平台原生路径的失败是软失败——运行时优雅降级为 JIT 编译而不是拒绝加载程序集。这对部署韧性很关键即使 dylib 缺失或加载失败应用仍可通过 IL 运行只是失去预编译性能收益。Host 回调get_native_code_data加载流程的关键是新引入的 host 回调。设计文档中host_runtime_contract 将更新以新增获取原生代码信息的回调并给出了两个结构与一个函数原型struct native_code_context { size_t size; // size of this struct const char* assembly_path; // component assembly path const char* owner_composite_name; // name from component R2R header }; struct native_code_data { size_t size; // size of this struct void* r2r_header_ptr; // ReadyToRun header size_t image_size; // size of the image void* image_base; // base address where the image was loaded }; bool get_native_code_data( const struct native_code_context* context, /*out*/ struct native_code_data* data );该回调的设计意图是把实际的加载动作完全留给 hosthost 可以dlopen一个共享库也可以使用静态链接进 host 自身的东西同时缓存策略也由 host 负责回调注释明确Any callbacks set on this contract are expected to be valid for the lifetime of the process。在仓库当前代码中该契约已落地于 host_runtime_contract.h两个结构体实际命名为host_runtime_contract_native_code_context与host_runtime_contract_native_code_data比设计文档中的native_code_context/native_code_data多了host_runtime_contract_前缀与头文件内其他类型保持一致字段与设计文档一一对应assembly_path、owner_composite_name、r2r_header_ptr、image_size、image_base每个结构体首字段均为size用于版本化演进回调以函数指针形式挂入host_runtime_contract结构体// Get native code data for the assembly specified by the supplied context bool(HOST_CONTRACT_CALLTYPE* get_native_code_data)( const struct host_runtime_contract_native_code_context* context, /*out*/ struct host_runtime_contract_native_code_data* data);从该头文件还可以看到整个 host 契约的全貌除get_native_code_data外还包括get_runtime_property读运行时属性、bundle_probe探测 app bundle、pinvoke_overrideP/Invoke 覆盖、external_assembly_probe探测外部程序集等既有回调。get_native_code_data与external_assembly_probe在形态上类似都涉及host 提供代码/数据段指针但前者额外携带 owner composite 名称与镜像基址/大小信息专门服务于平台原生 R2R 的头部定位。头格式与版本演进落点READYTORUN_HEADER的结构定义于 readytorun.hstruct READYTORUN_HEADER { DWORD Signature; // READYTORUN_SIGNATURE USHORT MajorVersion; // READYTORUN_VERSION_XXX USHORT MinorVersion; READYTORUN_CORE_HEADER CoreHeader; };其中READYTORUN_CORE_HEADER以Flags承载上述各READYTORUN_FLAG_*。与本设计直接相关的两个 Section 类型也定义在同一文件readytorun.hComponentAssemblies 115V4.1 加入列出 Composite 镜像中的 component assembliesOwnerCompositeExecutable 116V4.1 加入运行时第 3.a 步读取的正是这个 Section用于定位拥有该 component 的 Composite 镜像。READYTORUN_FLAG_PLATFORM_NATIVE_IMAGE的加入被记录为R2R Version 17.1readytorun.h这是 R2R 头版本演化中一次典型的非破坏性扩展旧运行时看到未知标志时仍可按既有路径处理PE 查找/加载或 IL 回退新运行时则能据此切换到平台原生消费路径。版本化设计是 R2R 兼容性保证的核心——如 readytorun-overview.md 所述格式中放入的每一项都是未来所有运行时都必须支持的责任因此设计趋于极简平台原生封装同样遵循这一原则能复用的 Section 布局与标志位语义尽量复用只新增必要的最小增量一个标志、一个回调、一个基础符号约定。总结与展望综合设计文档与仓库现状可以梳理出 .NET 11 ReadyToRun 平台原生封装的完整脉络层面关键决策仓库落点编译--obj-format macho默认pe仅 Composite R2R macOSCrossgen2RootCommand.cs符号导出RTR_HEADER可经--rtr-header-symbol-name覆盖指向READYTORUN_HEADERReadyToRunObjectWriter.cs标志位每个 component 设置READYTORUN_FLAG_COMPONENTREADYTORUN_FLAG_PLATFORM_NATIVE_IMAGER2R V17.1readytorun.h基础符号对象写入器使用__mh_dylib_headersubtractor 重定位模拟 RVAReadyToRunObjectWriter.csSection托管代码入__TEXT,__managedcode只读数据入__TEXT,__constfixup 表留__DATA,__data设计文档 NativeAOT 对齐约定运行时按标志位分流OwnerCompositeExecutable→ host 回调 → R2R 头失败回退 IL/JIThost_runtime_contract.h需要留意的是readytorun-platform-native-envelope.md 本身仍是一份进行中的设计文档其明示tentative high-level design并承诺实现过程中会持续更新本文档及总览/格式文档。仓库中已可见的标志位、CLI 选项与 host 契约回调证明该方向已开始落地但 dylib 链接步骤、运行时消费逻辑的最终形态如第 2 步非 component 不支持平台原生、第 3.d 步回退细节仍以文档演进与后续实现为准。对 R2R 格式整体结构感兴趣的读者可进一步阅读 readytorun-overview.md动机、版本气泡、版本韧性代码生成与 readytorun-format.mdSection 与 Fixup 的详细布局。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
