语言运行时标准库JIT编译编译器【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址https://gitcode.com/GitHub_Trending/runtime6/runtime点击查看免费下载本文是 dotnet/runtime 仓库中 CoreCLR 测试体系的 Unix 平台操作指南覆盖从构建 CoreCLR 本体、编译托管测试含-test/-dir/-tree子集选择、生成Core_Root布局到批量运行与单测调试、以及 PAL 层原生测试的完整链路。读完本文你将掌握src/tests/build.sh、src/tests/run.sh、runpaltests.sh等核心脚本的用法与底层行为能够在 Linux、macOS、FreeBSD 上独立完成 CoreCLR 的测试构建、运行与问题定位。前置先构建 CoreCLR 本体所有测试都运行在你自建的 CoreCLR 运行时之上因此第一步是完成 CoreCLR 产品构建。按 CoreCLR 构建指南 中的说明执行即可核心命令是./build.sh -subset clr 其他参数从构建指南可知脚本默认构建Debug配置无优化、断言全开若目标是跑测试推荐使用 CoreCLR 独有的Checked配置——它保留断言但开启原生编译优化运行速度远快于 Debug也是 CI 流水线运行测试的常规模式./build.sh -subset clr -configuration Checked构建产物位于artifacts/bin/coreclr/OS.架构.配置其中corerun命令行宿主、libcoreclr.so/libcoreclr.dylib运行时本体、System.Private.CoreLib.dll是测试运行时的关键组件。完整的测试操作步骤可参见 CoreCLR 测试总览本文聚焦 Unix 平台实操细节。构建测试套件构建测试需要 .NET CLIDotnet CLI。如果目标架构或操作系统本身不支持 Dotnet可以在任意平台先构建测试再拷贝过去。在 Unix 上构建测试只需./src/tests/build.sh默认情况下测试构建使用Release作为 libraries类库配置。要改用其他配置通过LibrariesConfiguration属性指定例如./src/tests/build.sh /p:LibrariesConfigurationDebug注意该参数是直接透传给 MSBuild 的/p:前缀因此与脚本自有的短横线风格参数不同。默认只构建Priority 0优先级 0的测试要同时构建优先级 1 的测试./src/tests/build.sh -priority1从 src/tests/build.sh 的源码可以印证这套行为脚本通过__Priority变量记录优先级默认__Priority0所有测试二进制输出统一放入artifacts/tests/coreclr/OS.架构.配置构建日志.log/.wrn/.err/.binlog则落在artifacts/log下。脚本还导出了__TestDir、__SkipManaged、__BuildTestProject等环境变量供 MSBuild 侧消费最终调用eng/common/msbuild.sh驱动src/tests/build.proj的TestBuild目标并以--warnAsError false关闭告警即错避免仓库中历史遗留的告警阻塞测试构建。生成 Core_Rootsrc/tests/build.sh会在测试构建过程中生成Core_Root目录其中包含运行测试所需的测试宿主corerun、类库以及 coreclr 产品二进制。如果只想生成 Core_Root 而不构建测试使用generatelayoutonly参数./src/tests/build.sh generatelayoutonly输出位于仓库根/artifacts/tests/coreclr/os.arch.configuration/Tests/Core_Root例如 Linux x64 Checked 构建对应artifacts/tests/coreclr/linux.x64.Checked/Tests/Core_Root。在 src/tests/build.sh 中-generatelayoutonly会将__GenerateLayoutOnly置 1从而跳过原生组件与托管测试的构建只执行布局生成。在跑测试前Core_Root必须由本次测试构建正确生成它是单测入口脚本定位运行时与类库的依据。构建测试子集全量构建src/tests下的整个测试树非常耗时-priority1模式下尤其明显而且在只改某一个测试时毫无必要。为此src/tests/build.sh提供了三种限定构建范围的选项可多次指定也可用分号分隔多个路径1)-test:测试项目—— 构建单个测试项目参数为项目文件路径绝对路径或相对src/tests的相对路径均可。示例src/tests/build.sh -test:JIT/Methodical/divrem/div/i4div_cs_do.csproj;JIT/Methodical/divrem/div/i8div_cs_do.csproj2)-dir:测试目录—— 构建目录内的全部测试项目参数为目录路径同样支持绝对路径或相对src/tests的相对路径。示例src/tests/build.sh -dir:JIT/Methodical/Arrays/huge;JIT/Methodical/divrem/div3)-tree:根目录—— 构建子树下的全部测试项目参数为子树根路径构建该子树范围内的所有测试项目。示例src/tests/build.sh -tree:baseservices/exceptions;JIT/Methodical从 src/tests/build.sh 的参数解析逻辑可见-test/-dir/-tree分别累积到__BuildTestProject、__BuildTestDir、__BuildTestTree三个变量再通过%3B分号转义拼接传给 MSBuild最终以-test/-dir/-tree对应的 MSBuild 属性限定TestBuild目标的作用范围。优先级过滤与子集正交请特别注意优先级过滤与测试子集指定是相互正交的。即使你明确指定构建某个测试只要它是 Pri1 测试就必须同时在命令行带上-priority1否则该测试会被跳过。这看起来有些反直觉但项目文档明确指出临时修复这一行为弊大于利且团队长期目标是彻底取消测试优先级机制。构建单个测试开发过程中经常需要快速构建单个测试。构建所需的全部工具都在coreclr子集产物中可以直接像使用 MSBuild 一样使用仓库根目录的./dotnet.sh msbuild但有几点注意事项。重要提醒必须传/p:TargetOS[osx|linux]。构建单个测试./dotnet.sh msbuild src/tests/path-to-proj-file /p:TargetOSTargetOS /p:ConfigurationBuildType例如在 Linux x64 上以 Checked 配置构建某个 JIT 测试./dotnet.sh msbuild src/tests/JIT/Methodical/divrem/div/i4div_cs_do.csproj /p:TargetOSlinux /p:ConfigurationChecked除了生成测试程序集该命令还会在测试输出目录中、紧邻测试程序集生成一个.sh启动脚本Windows 上对应.cmd。测试输出目录位于仓库根/artifacts/tests/coreclr/os.arch.configuration其子路径与测试在源码树中的位置一一对应。关于测试入口脚本的生成条件可参考 src/tests/Directory.Build.targets 中的GenerateRunScript逻辑默认测试类型BuildAndRun会同时产出可执行文件与运行脚本。运行测试以下指令假设 Unix 机器上 CoreCLR 仓库已克隆到/mnt/coreclr实际使用时可替换为你的仓库路径。测试构建完成后src/tests/build.sh已正确设置好Core_Root目录接着即可批量运行./src/tests/run.sh x64 checked其中第一个位置参数是架构如x64第二个是构建配置debug/checked/release。查看全部参数请使用帮助命令./src/tests/run.sh -h从 src/tests/run.sh 的源码看run.sh实际上是一个参数转译器它解析位置参数与长选项后最终调用跨平台的python3 src/tests/run.py完成实际执行脚本会优先探测python3否则退回python。它支持的选项非常丰富与测试调试强相关的主要有选项作用--sequential串行运行测试默认并行--jitstressn以DOTNET_JitStressn运行JIT 压力测试--jitstressregsn以DOTNET_JitStressRegsn运行--jitminopts以DOTNET_JITMinOpts1运行--gcstressleveln以DOTNET_GCStressn运行GC 压力测试0/1/2/4/8/16 分别代表不同压力档位--gcnamen以DOTNET_GCNamen指定 GC 实现--useServerGC启用服务器 GCDOTNET_gcServer1--ilasmroundtrip对测试做 ilasm 往返round trip检查--runincontext在每个可卸载的AssemblyLoadContext中运行测试--tieringtest运行测试以促使 tier1 重新 JIT--runcrossgen2tests运行 Crossgen2 编译的 ReadyToRun 测试--tree路径只运行指定子树下的测试如JIT/Regression--testRootDir路径指定测试构建根目录--coreRootDir路径指定 Core_Root 位置--test-env路径指定设置测试环境变量的脚本批跑结束后结果报告会生成在artifacts/log下TestRun_架构_配置.html失败测试清单写入TestRunResults_OS_架构_配置.err单个测试的详细输出则落在测试根目录下的Reports子目录中。不支持与暂时禁用的测试为了能在单一目标平台上构建所有目标平台的测试测试项目使用条件属性CLRTestTargetUnsupported Condition...true/CLRTestTargetUnsupported该属性会在默认构建中禁用该测试的构建同时也会在 bash/batch 包装脚本中禁用其运行。但当build.*脚本传入allTargets选项时测试仍可在 CI 中为任何目标构建。这一机制在 src/tests/Directory.Build.targets 中有精确实现_WillCLRTestProjectBuild属性综合判定CLRTestBuildAllTargets与CLRTestTargetUnsupported当「未指定allTargets且目标不支持」时置为false从而跳过构建。仓库中有大量真实用例例如 GC/API/Frozen/Frozen.csprojCLRTestTargetUnsupported Condition$(RuntimeFlavor) ! coreclrtrue/CLRTestTargetUnsupported而永远不应构建或运行的测试则标记为DisableProjectBuildtrue/DisableProjectBuild该属性不应基于 Target 属性做条件化这样所有测试才能为allTargets构建在 src/tests/Directory.Build.targets 中_WillCLRTestProjectBuild同样会对DisableProjectBuild true的项目返回false并最终通过导入Common\nobuild.targets让构建目标变成空操作。运行单个测试构建完单个测试后参见上文「构建单个测试」按以下两步运行将CORE_ROOT环境变量设置为 Core_Root 目录 的路径export CORE_ROOT仓库根/artifacts/tests/coreclr/os.arch.configuration/Tests/Core_Root运行该测试生成目录下的.sh脚本cd 仓库根/artifacts/tests/coreclr/os.arch.configuration/测试子路径 ./测试名.sh测试入口脚本还支持-coreroot路径直接指定 Core_Root此时可省略环境变量、-debug调试器路径挂载调试器、-env.env 文件注入环境变量其参数风格与corerun基本一致。构建脚本在构建完成后也会打印单测运行提示参见 src/tests/build.sh 末尾输出格式为bash TestBinDir/__TEST_PATH__/__TEST_NAME__.sh -coreroot${CORE_ROOT}。PAL 测试仅 macOS 与 LinuxPALPlatform Abstraction Layer测试用于验证 CoreCLR 原生层的平台抽象实现是 Unix 平台专属的测试套件。构建 PAL 测试在 Unix 机器上用clr.paltests子集构建 CoreCLR 及 PAL 测试./build.sh clr.paltests运行 PAL 测试运行全部测试包含被禁用的测试./src/coreclr/pal/tests/palsuite/runpaltests.sh $(pwd)/artifacts/bin/coreclr/$(uname).x64.Debug/paltests # macOS 上请将 $(uname) 替换为 osx只运行构建平台对应的已启用测试artifacts/bin/coreclr/$(uname).x64.Debug/paltests/runpaltests.sh $(pwd)/artifacts/bin/coreclr/$(uname).x64.Debug/paltests # macOS 上请将 $(uname) 替换为 osx只运行特定测试在本地编辑src/coreclr/pal/tests/palsuite/paltestlist.txt删除不想运行的条目即可注意不要把本地改动提交入库。从 runpaltests.sh 的实现看脚本会从传入的构建根目录读取paltestlist.txt测试清单将LD_LIBRARY_PATH指向测试构建目录然后逐条执行每个测试并记录退出码退出码 0 记为 Pass否则记为 Fail 并写入失败列表。每个测试在独立的工作目录中运行以避免脏状态干扰最终汇总输出 xUnit 风格的结果文件/tmp/PalTestOutput/default/pal_tests.xml脚本还支持可选的第二、三个参数分别指定输出拷贝目录与临时工作目录以便在同一台机器上并行跑多组 PAL 测试。测试结束后脚本以失败测试数量作为退出码。要在 CI 中禁用测试编辑src/coreclr/pal/tests/palsuite/issues.targets即可。该文件以 MSBuildExcludeList形式按TargetArchitecture/TargetOS组合排除特定用例并关联 issue例如 issues.targets 中的真实条目ItemGroup Condition$(TargetArchitecture) x64 and $(TargetOS) linux ExcludeList Includeeventprovider/eventprovidertest Issuehttps://github.com/dotnet/runtime/issues/42291/Issue /ExcludeList /ItemGroup这表示在 Linux x64 上跳过eventprovider/eventprovidertest同时用Issue记录追踪链接便于后续回归修复后移除排除项。测试失败排查建议批跑结束后若存在失败测试可在每个测试对应的Reports目录artifacts/tests/coreclr/OS.架构.配置/Reports/测试路径中查看两类关键文件测试名.output.txt测试自身全部日志输出与测试名.error.txt测试进程崩溃时corerun报告的错误信息。报告中还会包含测试的完整执行命令可据此直接复现设置好CORE_ROOT后手动运行该命令或用-debug挂载调试器深入定位。关于测试基础设施的更完整说明可继续阅读 CoreCLR 测试总览其中还涵盖测试优先级、merged test runner 与RequiresProcessIsolation等机制。赞分享语言运行时标准库JIT编译编译器【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址https://gitcode.com/GitHub_Trending/runtime6/runtime点击查看免费下载相关推荐如何轻松配置Windows和Office面向新手的终极解决方案指南如何轻松配置Windows和Office面向新手的终极解决方案指南 还在为Windows系统频繁弹出配置提示而烦恼吗Office突然变成只读模式无法保存文件语言运行时标准库JIT编译编译器在 .NET 运行时仓库中构建、运行与调试 Android 上的 CoreCLR完整开发者工作流在 .NET 运行时仓库中构建、运行与调试 Android 上的 CoreCLR完整开发者工作流 导读 本文基于 .NET 运行时仓库dotnet/runt语言运行时标准库JIT编译编译器dotnet/runtime 如何生成 Core_Root 并构建、运行 CoreCLR 测试套件dotnet/runtime 如何生成 Core_Root 并构建、运行 CoreCLR 测试套件 在 dotnet/runtime 仓库中修改了 CoreC语言运行时标准库JIT编译编译器上一篇VidBee轻量级模式低资源占用的视频下载方案下一篇dart-collect-coverageDart 与 Flutter 项目测试覆盖率采集与 LCOV 报告生成实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考