dotnet core 在 MIPS64 下的移值进度

本文仍处于修订中

写在开始前

咱们的主要业务基于 dotnet core 2.x 与 3.1 完成，目前 dotnet core 3.1 支持的 CPU 架构列表中还不包含龙芯，且在 gitlab issue 中表示官方当前没有对 MIPS 的支持计划。

官方支持的具体操做系统与 CPU 架构列表见 [Download .NET Core 3.1](https://dotnet.microsoft.com/download/dotnet-core/3.1

6月下旬，龙芯团队宣布在 dotnet/coreclr 基础上完成了MIPS64 的移植工做 Open-sourcing CoreCLR MIPS64 Port #38069，计划实现 3.x 版本并贡献到上游 dotnet/runtime。

按照相关 issue 里的指引，这里对移值仓库进行了编译和一些测试。

具体的进度

做为下游开发者，想知道距离生产环境使用还有多远，必须先说起 dotnet core 应用程序的发布/部署方式

1. dotnet core 支持两种方式的发布/部署

• 独立应用(self-contained)
• 依赖于运行时(runtime-dependent)

前者包含可执行文件(exe)，没法跨平台；后者生成了跨平台的二进制文件(dll)，须要运行环境预先安装好运行时。关于部署策略的详细信息，能够参考.NET Core application publishing overview。

发布独立应用须要针对特定操做系统及 CPU 架构编译并包含相应运行时，实际开发中咱们以依赖于运行时的方式交付，配合预先准备的包含运行时(runtime)的 docker 镜像完成部署。

微软官方 aspnet core 示例中的 Dockerfile

# ... 
FROM mcr.microsoft.com/dotnet/core/runtime:3.1
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet"，"dotnetapp.dll"]

2. dotnet core 的组成部分

做为编译型语言，和 Java 源代码被 javac 编译为字节码再交由 JVM 运行同样，csharp/vb.net 等源代码被编译为内容主要是 IL(中间语言，平台无关)的 Windows PE 文件(可用于全部操做系统)，而后交由 CLR 运行。

dotnet core 由如下若干部分组成：

• 运行时与框架库，包含 .NET Core Runtime 与 ASP.NET Core Runtime，平台特定
• SDK 和编译器：开发相关
• dotnet 命令：启动 dotnet 应用及做为交互式工具链

mono，unity3d 都是运行时实现，在此略说起

由前文的 Dockerfile 能够看到，依赖于运行时的 dotnet core 应用经过 dotnet xxxx.dll 运行，这里有若干层意义：

1. dotnet 提供了 Host(宿主/主机)能力，由于依赖于运行时(runtime-dependent)的 dotnet core 应用并非可执行文件，须要相似 JVM 的机制运行起来
2. dotnet 以交互式命令将 runtime 与 sdk 集合在一块儿，成为完整的工具链

而 dotnet/coreclr 编译结果并不包含可执行的 dotnet 命令，运行/测试已发布的 dotnet core 应用有如下选择

• 编写本机/原生代码，参考 Write a custom .NET Core host to control the .NET runtime from your native code。
• 使用编译获得的 corerun，参考 Using CoreRun To Run .NET Core Application。

当前的交付/部署体验都是经过 dotnet 命令进行的，获取该命令须要更多的工做，接下来是龙芯团队的移值工做的说明。

龙芯团队的工做

龙芯团队的工做在 19 年 7 月份开始，当时的 dotnet core源码结构、功能与如今的变动以下表。

原仓库	移值仓库	功能	释出	变动
dotnet/coreclr	gsvm/coreclr	运行时源码		合并入 dotnet/runtime
dotnet/corefx	gsvm/corefx	标准库源码	2020/7/7	合并入 dotnet/runtime
dotnet/core-setup	gsvm/core-setup	编译仓库	2020/7/7	合并入 dotnet/runtime
dotnet/cli		命令行工具链源码		合并入 dotnet/sdk

dotnet/core-setup 比较特殊，它是用来用来编译 runtime，类库和宿主程序的仓库，注意直到这一步 dotnet 命令才终于可用。

本地编译 gsvm/coreclr

龙芯团队首份释出的源码是 dotnet/coreclr。按照社区的沟通记录，因为依赖复杂，建议基于 docker 进行编译

git clone https://github.com/gsvm/coreclr.git
cd coreclr
docker run --rm -v $(pwd):/coreclr -w /coreclr aoqi/dotnet-buildtools:loongson3a-loongnix-1.0-llvm8ld ./build.sh -skiptests -ignorewarnings release

注意使用docker manifest inspect可知，镜像 aoqi/dotnet-buildtools:loongson3a-loongnix-1.0-llvm8ld 仅适用于龙芯操做系统，更多内容请参考 龙芯3A4000 开发机编译CoreCLR 环境 #6

做者使用的服务器使用 uname -p 输出的是 mips64el 而不是 mips64，前者包含了字节序信息，会致使 gsvm/coreclr 中相关脚本对 CPU 架构的断言失败，被相关人士认为违反了分发版本的命名规则，因此后续使用了交叉编译。

交叉编译 gsvm/coreclr

若是手边已经有 x64 服务器，基于 docker 进行交叉编译也是不错的选择，咱们能够将编译结果 scp/rsync 到龙芯服务器。

docker run --rm -v $(pwd):/coreclr -w /coreclr -e ROOTFS_DIR=/crossrootfs/mips64el aoqi/dotnet-buildtools:x86_64-ubuntu-16.04-c103199-20180628134544-upstream-cross-mips64el ./build.sh release ignorewarnings mips64 cross skipcrossgen

编译耗时很少，但连接步骤须要使用大量的内存，做者最初使用了一台腾迅云低配主机都在进度 87% 时失败，更换使用一台更高配置服务器后编译成功，相关讨论可见于 cross compile failed ...

交叉编译 gsvm/corefx

7月7日龙芯团队释出了 dotnet/corefx 和 dotnet/core-setup 仓库，编译方法以下，参考 cross-building.md。

git clone https://github.com/gsvm/corefx.git
cd corefx
docker run --rm -v $(pwd):/corefx -w /corefx -e ROOTFS_DIR=/crossrootfs/mips64el aoqi/dotnet-buildtools:x86_64-ubuntu-16.04-c103199-20180628134544-upstream-cross-mips64el-corefx ./src/Native/build-native.sh mips64 debug cross ignorewarnings cmakeargs -DOBJCOPY=/usr/lib/llvm-6.0/bin/llvm-objcopy

本地编译

docker run --rm -v $(pwd):/corefx -w /corefx -e ROOTFS_DIR=/crossrootfs/mips64el_loongnix aoqi/dotnet-buildtools:x86_64-ubuntu-16.04-c103199-20180628134544-upstream-cross-mips64el-corefx ./src/Native/build-native.sh mips64 debug cross ignorewarnings cmakeargs -DOBJCOPY=/usr/lib/llvm-6.0/bin/llvm-objcopy

leoninew 原创，转载请注明来自博客园