Merge pull request #186 from xen0n/twil

TWiL 49
loongson-community · May 20, 2024 · 30e5960 · 30e5960
2 parents 8a39a31 + 944e855
commit 30e5960
Show file tree

Hide file tree

Showing 3 changed files with 98 additions and 12 deletions.
diff --git a/docs/baseline-reference.md b/docs/baseline-reference.md
@@ -49,19 +49,24 @@ sidebar_position: 5
 * Linux 方面，支持了 KVM 虚拟化。
 * :wrench: 支持了更多 LoongArch v1.10 新增指令与语义变化等。
     - 预计将支持 16 字节原子操作 :wrench:：[tracking issue](https://github.com/loongson-community/discussions/issues/16)。
+* 完整的 TLSDESC 支持？
+* BFD 链接器的 `DT_RELR` 支持？
+* TBD
 
 ## 2024Q2 {#2024q2}
 
 |Binutils|GCC|Linux|glibc|LLVM|Rust|Go |
 |:------:|:-:|:---:|:---:|:--:|:--:|:-:|
-|2.42|14.x|6.6 LTS|2.39|18|1.74.x|1.22.x|
+|2.42|14.x|6.6 LTS|2.39|18|1.76.x|1.22.x|
 
 这是 LoongArch 新世界高速发展过程中的第二条基线，体现了大尺度协同研发中众人得以完成的重大迭代，以及众多小修小补。
 
+LoongArch v1.00 的功能支持在本条基线终于趋近完整。除此之外，更广泛的社区参与、更密切的合作、更及时的迭代，也意味着更多现代化特性从此基线开始被逐渐引入。
+
 本时期/本基线的主要特点有：
 
 * 部分实现了 LoongArch ELF psABI v20231219（整体版本号 v2.30）。
-    - v20230519：支持了 linker relaxation（链接器松弛）：GNU 工具链的支持较完善，LLVM 工具链只实现了兼容性所必须的部分。可能仍有一些坑。
+    - v20230519：基本支持了 linker relaxation（链接器松弛）：GNU 工具链的支持较完善，LLVM 工具链只实现了兼容性所必须的部分。可能仍有一些坑。
     - v20231102：对于 `medium` 代码模型的过程调用，采用了相邻的 `pcaddu18i + jirl` 配合
       `R_LARCH_CALL36` 的正确做法。
       先前的取巧做法仍受支持；这仅仅是出于兼容存量二进制的考虑，不建议产生增量。
@@ -70,10 +75,10 @@ sidebar_position: 5
       对于存量的目标代码，如果有不相邻且跨了 4KiB 地址边界的这样一组拼接地址指令，那么它们将被错误链接，无解：
       请打包者们密切关注涉及了 `extreme` 代码模型的软件（一般是大型项目或涉及特别底层的细节），确保生成的目标代码符合预期。
 * 首度支持了 LoongArch v1.00 全量指令。可以汇编、反汇编、在程序中自由使用了。
-  但 KVM 虚拟化功能未能赶上 Linux 6.6 这一 2023 年的 LTS 版本。
 * 支持了 LoongArch v1.10 新增指令的汇编、反汇编，部分支持了代码生成。如 gcc 为控制 32 位除法 erratum 与 `frecipe` 的使用，新增了命令行参数。
 * 编译器方面，初步具备了自动向量化能力。
 * 首度获得了 Rust 语言支持。可用 Rust 为 Linux glibc 环境，以及裸机环境开发了。
+* Linux 方面，KVM 虚拟化功能未能赶上 Linux 6.6 这一 2023 年末的 LTS 版本。
 
 ## 2023Q1 {#2023q1}
 

diff --git a/docs/old-and-new-worlds.md b/docs/old-and-new-worlds.md
@@ -212,13 +212,13 @@ zsh: 没有那个文件或目录: ./foo
 
 可能是由于未使用正确的 Go 工具链，导致不经意间构建了与您预期 ABI 相异的二进制。
 
-* 为旧世界发行版构建，必须搭配使用龙芯提供的 Go 工具链与 goproxy 源。
-* 为新世界发行版构建，必须搭配使用上游版本的 Go 工具链，不可使用龙芯源。
+* 为旧世界发行版构建，必须搭配使用龙芯提供的 Go 工具链与 goproxy 源（所谓「龙芯源」；见下）。
+* 为新世界发行版构建，必须搭配使用上游版本的 Go 工具链，不可使用「龙芯源」。
 
-具体而言，适配异世界的 Go 程序初始化过程中必须的一次 `rt_sigprocmask`
+具体而言，Go 程序在异世界运行时，初始化过程中必须的一次 `rt_sigprocmask`
 系统调用会由于它使用的 `NSIG` 常量定义与当前运行内核不同而失败，
-此时 Go 会故意访问一个非法地址直接崩溃
-（因为此时从程序视角看，必然成功的系统调用居然失败，证明内核服务已经不再可靠，继续下去没有意义）。
+此时 Go 会故意访问一个非法地址直接崩溃：
+此时从程序视角看，必然成功的系统调用居然失败，这说明内核服务已经不再可靠，继续下去没有意义。
 
 ### 龙芯提供了很多镜像源（「龙芯源」），我能用吗？
 
@@ -237,9 +237,9 @@ zsh: 没有那个文件或目录: ./foo
 
 [loongson-cloud-community]: https://loongson-cloud-community.github.io/Loongson-Cloud-Community
 
-由于旧世界 ABI、API 并未（也不会）上游，那些需要关心系统底层 ABI、API 细节的包，
-其正式版本（也就是从上游或常规镜像站下到的版本）在旧世界不可能正常工作：要么没适配过龙架构，要么适配的是新世界。
+由于旧世界 ABI、API 并未上游，也不会被上游，那些需要关心系统底层 ABI、API 细节的包，
+其正式版本——也就是从上游或常规镜像站下到的版本——在旧世界不可能正常工作：要么没适配过龙架构，要么适配的是新世界。
 因此为了方便为旧世界适配软件，龙芯搭建了这些源：那些会受影响的包和相应版本，在这些源里被针对旧世界改过了。
 
-这就是为何新世界开发者不可贪图方便使用它们：有的包会下到坏的版本，完整性校验不会通过，逻辑也是坏的。
-同样，这也是旧世界开发者必须开启它们，并且关闭相应的完整性校验的原因。
+这就是为何新世界开发者不可贪图方便使用它们：从这些软件源中下载的有些包，对新世界而言反而是坏的，更何况完整性校验不会通过——龙芯提供魔改代码的行为与「中间人攻击」没有外观上的差别。
+换个角度看，这也是旧世界开发者必须开启它们，并且关闭相应的完整性校验的原因。
diff --git a/newsletter/2024-05-20-this-week-in-loongarch-49.md b/newsletter/2024-05-20-this-week-in-loongarch-49.md
@@ -0,0 +1,81 @@
+---
+slug: this-week-in-loongarch-49
+title: 每周一龙：第 49 期
+authors: [xen0n]
+date: 2024-05-20T13:00:00+08:00
+tags: [每周一龙]
+---
+
+每周一都为大家报道 LoongArch 社区最前线的第一手新鲜资讯！
+上周的进展主要有 Linux、工具链与 Mono 龙架构移植主线化。
+详情点进来看！
+
+<!-- truncate -->
+
+如无特别说明，文中提及的日期、时间都为北京时间（UTC+8）。
+
+## 先「马」再看 {#marked-projects}
+
+本栏目的内容具有一定延续性，将持续追踪报道 LoongArch 领域的重要或长期项目（坑）。
+
+### Linux {#linux}
+
+Huacai Chen [新增了](https://lore.kernel.org/loongarch/[email protected]/)
+IRQ work 类型的处理器间中断（IPI）支持，这使得在硬件中断上下文进行 IRQ work 成为可能，也是后续支持
+`NOHZ_FULL` 配置的前提。`NOHZ_FULL` 意为允许在一个或一些核上完全关闭定时器中断，
+这对于一些对硬件行为的确定性、延迟要求极端苛刻的场景，很有帮助，甚至不可或缺。
+
+Huacai Chen [默认开启了](https://lore.kernel.org/loongarch/[email protected]/)
+BPF JIT。
+
+Bibo Mao [贴出了](https://lore.kernel.org/loongarch/[email protected]/)
+LoongArch KVM 的 LBT 支持。不日即可在 KVM 虚拟机中用上 LBT 扩展指令。
+
+### 工具链 {#toolchain}
+
+#### binutils {#binutils}
+
+mengqinggang 在邮件列表上[询问了](https://sourceware.org/pipermail/binutils/2024-May/134123.html)关于性能侧写（profiling）工具
+`gprofng` 移植的技术细节。这表明龙芯已经将此工具的移植提上议事日程了。
+
+#### LLVM {#llvm}
+
+[heiher] 用上了 32 位除法、取余指令，[消除了]((https://github.com/llvm/llvm-project/pull/92205)这些
+32 位操作的编译产物中，对结果进行的多余符号扩展。
+
+[heiher] 还为 LoongArch 上的循环优化[开启了](https://github.com/llvm/llvm-project/pull/92629/files)交织向量化（interleaved vectorization）工序（pass），初期使用默认的交织系数 2。
+
+[wangleiat] [允许了](https://github.com/llvm/llvm-project/pull/92222)在编译中使用尚未冻结的
+ABI：ILP32S、ILP32F 与 LP64F，把致命错误降级为了警告。
+随后，又[引入了](https://github.com/llvm/llvm-project/pull/92223)「目标特性隐含 ABI」（feature-implied ABI）的概念，
+以修复编译时使用的目标特性与显式指定的 ABI（如果有的话）、「目标隐含 ABI」（target-implied ABI）都不兼容的情况下，编译产物的
+ABI 属性设置错误的问题。例如：如果使用 `loongarch64` 作为目标元组，并明确制定
+
+[wangleiat] 还[再次提议引入](https://github.com/llvm/llvm-project/pull/92483)模拟 TLS（emulated TLS）支持。根据提交说明，此特性应该是开源鸿蒙（OHOS）所需要的；先前人们基于此特性已经过时而不希望 LoongArch 作为一个新架构而仍然支持，目前看来可能要重新评估这一决定。
+
+[wangleiat] 还消除了对库调用（libcalls，如对软浮点例程的调用）参数的多余符号扩展：[补丁甲](https://github.com/llvm/llvm-project/pull/92375)、[补丁乙](https://github.com/llvm/llvm-project/pull/92376)。
+
+[heiher]: https://github.com/heiher
+[wangleiat]: https://github.com/wangleiat
+
+## 杂闻播报 {#assorted-news}
+
+[lrzlin] 向 PCRE2 正则表达式库所用的 JIT 基础库 sljit
+[增加了](https://github.com/zherczeg/sljit/pull/247) LSX 与 LASX 支持。
+
+龙芯做的 Mono 龙架构移植[已进入上游](https://github.com/mono/mono/pull/21769)（链接目标为五个 PRs 中的最后一个）。Mono
+是在微软的官方 .NET 运行时开源之前，由社区开发的 .NET 运行时；目前最著名的
+Mono 使用者是游戏引擎 Unity。此次 Mono 主线加入 LoongArch 支持，有助于降低那些需要将其
+Unity 项目向 LoongArch 部署的开发者的魔改工作量。同时，雄心勃勃的读者朋友或许也可以少许期待一下未来
+Unity——或者至少其国区版本「团结引擎」——增加官方 LoongArch 支持的可能性。
+
+[lrzlin]: https://github.com/lrzlin
+
+## 张贴栏 {#bulletin}
+
+本栏目可供张贴公益性质的各种信息。
+
+* 您可在 GitHub [浏览](https://github.com/loongson-community/discussions/labels/%E8%8B%B1%E9%9B%84%E5%B8%96)目前所有开放的英雄帖。
+* 本周报[持续接受网友投稿][call-for-submissions]。欢迎来上游坐坐！
+
+[call-for-submissions]: https://github.com/loongson-community/areweloongyet/issues/16