龙架构双周会“生肉”学习法：交叉编译与QEMU运行实践

如果你也在关注龙架构LoongArch生态应该经常遇到一类“生肉”技术资源官方双周会以原声录像的形式发布没有中文字幕信息密度又高。2026 年 8 月 6 日的第 7 期双周会就是这样一场硬核内容。很多人点开视频几分钟后就被术语和口音劝退转头去等二手笔记。但技术会议里真正有价值的讨论细节往往就藏在那些没有翻译的对话里。这篇文章不会替你复述某位嘉宾的每一句原话而是想分享一套面对“生肉”资源更高效的学习方法同时把龙架构相关的基础概念、交叉编译工具链、QEMU 模拟运行完整串联起来。读完之后你会明白双周会里反复出现的新名词到底在讲什么在普通 x86 开发机上如何编译并运行一个 LoongArch 程序长期跟踪龙架构生态时应该重点关注哪些信息源和风险点。1. 龙架构双周会是什么1.1 双周会的定位龙架构LoongArch是龙芯中科推出的指令集架构不是某个开发板上的一次性实验而是覆盖桌面、服务器、嵌入式的完整生态。为了把内核、编译器、虚拟机、发行版等不同方向的开发者聚到一起社区以双周为周期举办公开技术例会这就是大家常说的“龙架构双周会”。双周会的典型内容是各子系统负责人同步进展例如 Linux 内核最近合入了哪些 LoongArch 补丁、GCC 工具链在优化层面有什么调整、QEMU 虚拟化支持到了哪一步、某个发行版是否已经能在龙芯设备上正常启动。这类会议本质上不是产品发布会而是社区协同开发的一部分。第 7 期选在 2026 年 8 月 6 日延续了双周更新的节奏。“生肉”这个词在技术圈里一般指没有翻译、没有字幕的原声视频。技术会议的生肉和动画生肉不太一样动画生肉可能只有字幕组在等但技术会议生肉本身就是第一手材料很多参与者在会议现场会直接讨论补丁的取舍、ABI 兼容性问题、内核启动流程等细节。如果只依赖别人整理好的二手笔记这些过程信息很容易丢失。1.2 为什么“生肉”也值得看不少开发者看到“外语原声”四个字就打了退堂鼓觉得先等别人翻译更稳妥。但技术会议的重点从来不是语言而是信息。一场四十分钟的双周会通常包含三到五个主题报告每个报告背后都有对应的代码提交记录、设计文档或邮件列表讨论。也就是说即使你漏听了一句话只要能抓住关键词会后依然可以通过资料把上下文补回来。更重要的一点是二手笔记往往带着整理者自己的筛选。整理者觉得不重要的部分可能是你当前项目最需要的部分。比如某次双周会提到了内核配置项的变更整理者可能一句话带过但如果你正在做龙芯设备的系统裁剪这个配置项能不能编译通过就直接影响交付时间。直接接触生肉资源至少能保证信息不经过他人二次简化。1.3 双周会适合哪类开发者做国产化适配、信创项目的后端或系统开发工程师需要提前判断龙架构生态变化编译器、内核、虚拟化方向的研究者关注工具链和内核补丁的演进方向需要在龙芯机器或 LoongArch 模拟环境中配置 CI 的运维和平台工程师对计算机体系结构感兴趣的在校学生想从实际会议中理解一个指令集生态如何运转。哪怕目前和龙架构没有直接业务关系花少量时间了解一个新兴指令集生态如何协作也能帮助你建立对 CPU、编译器、操作系统之间关系的整体认识。2. “生肉”会议食用策略2.1 看之前先建立信息框架面对没有字幕的技术录像最忌讳的是打开视频从头看到尾被动地等自己“听懂”。更有效的方法是在看视频之前先把会议的信息框架搭起来。你可以在公开渠道找这些材料会议议程或议题列表判断本期覆盖范围已公开的 PR、补丁标题推测每个报告可能讲什么与议题相关的 Release Notes 或发行说明了解背景社区邮件列表里的讨论串里面往往有设计动机。有了这个框架后看视频就变成了“对照验证”而不是“盲听”。听到某个关键词时你能快速对应到具体模块理解成本会低很多。2.2 边看边记三类笔记我建议把会议笔记分成三列发生了什么、为什么发生、我要不要跟进。第一列记录客观事实比如“内核新增了对某类指令的支持”。第二列记录你对动机的理解比如“可能是为了优化某些场景下的上下文切换开销”。第三列记录行动项比如“下周在自己的环境里编译测试这个分支”。生肉视频不适合逐句精听更适合带着问题跳着看。如果你发现某个议题和当前工作无关可以直接跳到下一个时间点。技术会议不是电影不需要照顾导演的节奏。2.3 用官方资料补全理解原声录像没有字幕那就在录像之外找“字幕”。很多技术会议在结束后会公开讲稿、幻灯片或者提交记录这些材料本身就是文字的“熟肉”。把录像和文字材料放在一起看录像负责还原语气和重点文字负责确认名词拼写和代码细节。需要注意的是只使用公开授权的材料。不要传播未授权的盗录资源也不要因为“生肉”没有翻译就随意使用机器翻译工具把非公开内容扩散出去。学习归学习版权和技术合规的边界要清楚。3. 龙架构核心概念扫盲3.1 LoongArch 到底指什么LoongArch 是龙芯中科发布的指令集架构提供了从底层指令编码到上层 ABI 的一整套规范。指令集架构ISA是 CPU 和软件之间的约定编译器把高级语言翻译成指令CPU 按指令完成计算ISA 就是这套翻译结果必须遵守的“语法”。龙架构属于 RISC精简指令集计算风格指令长度、编码方式、通用寄存器数量都有明确规范。根据公开资料LoongArch 分为 32 位和 64 位版本桌面和服务器场景更常接触的是 64 位部分。双周会里提到的内核支持、工具链适配通常默认围绕 64 位 LoongArch 展开。如果你以前接触过 ARM64、RISC-V会发现龙架构在很多概念上是互通的比如通用寄存器、加载存储指令、异常处理流程等。不同之处在于具体编码规则和平台特有的扩展机制。3.2 双周会里经常出现的名词内核Linux Kernel操作系统内核需要支持 LoongArch 的启动、中断、内存管理、调度等能力工具链ToolchainGCC、Binutils、LLVM/Clang 等编译器相关组件负责把源码变成可执行文件ABI / psABI应用程序二进制接口规定函数调用、参数传递、寄存器使用等规则UEFI / ACPI固件和电源管理相关规范影响系统能否正常引导QEMU开源模拟器用于在没有龙芯硬件的情况下运行 LoongArch 程序发行版适配操作系统发行版需要在 LoongArch 上完成软件包编译和稳定性验证。这些名词在双周会里经常交替出现。初学者不需要一开始就全部弄懂先记住它们各自解决什么问题再遇到时就不会觉得陌生。3.3 为什么要关注 ABI 和工具链ABI 是二进制兼容性的基石。如果一个程序按旧 ABI 编译换到新 ABI 的系统上就可能出现函数调用参数错位、栈布局不一致等问题。龙架构生态还在快速演进psABI 偶尔会有修订双周会上经常能听到相关讨论。工具链则是生态的“入口”。内核、发行版、应用软件最终都要通过编译器生成 LoongArch 指令。GCC 或 LLVM 对龙架构支持得好不好直接决定了有多少开源软件能顺利编译。看懂双周会里的工具链议题也就看懂了龙架构生态的发展瓶颈在哪里。4. 在本地搭建龙架构验证环境4.1 环境说明与依赖安装这一节的实验环境是常见的 x86_64 Linux 开发机发行版以 Debian/Ubuntu 系为例。目标不是拥有一台龙芯真机而是通过交叉编译器生成 LoongArch 可执行文件再用 QEMU 用户态模拟器运行它。先更新软件源并安装工具sudo apt update sudo apt install gcc-loongarch64-linux-gnu qemu-user-static安装完成后确认编译器可用loongarch64-linux-gnu-gcc --version如果你的发行版软件源里没有这个包名可以去龙芯官网或开源社区获取官方工具链原理是一样的。不同发行版的包名可能略有差异但“交叉编译器前缀 qemu 用户态模拟器”的组合思路不变。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。4.2 编写最小程序创建一个测试目录并在其中编写 hello.c// 文件路径hello.c #include stdio.h int main(void) { printf(Hello, LoongArch!\n); return 0; }这段代码不包含任何平台相关的写法标准 C 代码在任何架构上语义一致。接下来就看交叉编译器能否把这段代码变成 LoongArch 指令。4.3 交叉编译与静态运行使用带 loongarch64 前缀的编译器进行编译loongarch64-linux-gnu-gcc -static -o hello hello.c命令中的-static表示静态链接把标准库直接编进可执行文件里。这样做的目的是减少对目标系统动态链接器的依赖在 QEMU 用户态下运行更省事。编译完成后先用 file 命令查看产物file hello正常会看到类似 “ELF 64-bit LSB executable, LoongArch” 的描述说明文件确实是 LoongArch 架构的二进制格式。然后用 QEMU 用户态模拟器运行qemu-loongarch64 ./hello如果一切正常终端会输出Hello, LoongArch!如果你尝试在 x86_64 主机上直接执行./hello大概率会遇到 “Exec format error”。这是因为没有通过模拟器CPU 无法解析 LoongArch 指令。4.4 检查二进制信息交叉工具链自带的 readelf 可以查看 ELF 文件头loongarch64-linux-gnu-readelf -h hello在输出里关注 Machine 字段和 Flags 字段可以确认这是一个 LoongArch 目标文件。这步操作在排查问题时非常有用比如怀疑编译产物架构不对时用 readelf 一眼就能定位。5. 实战交叉编译并运行一个带文件读写的程序5.1 程序功能hello world 只能证明交叉编译器能工作还不能证明标准库文件操作、系统调用在 QEMU 环境下正常运转。这一节我们写一个更接近真实场景的小程序读取命令行传入的文本文件统计文件中的字符数并输出。这个程序虽然简单但涉及命令行参数解析、文件打开、读取、关闭、标准错误输出等多个环节足以验证交叉编译和 QEMU 模拟的组合是否完整。5.2 完整代码创建 count_chars.c// 文件路径count_chars.c #include stdio.h #include stdlib.h int main(int argc, char *argv[]) { FILE *fp; int ch; long count 0; if (argc ! 2) { fprintf(stderr, Usage: %s file\n, argv[0]); return 1; } fp fopen(argv[1], r); if (fp NULL) { perror(fopen); return 1; } while ((ch fgetc(fp)) ! EOF) { count; } fclose(fp); printf(chars: %ld\n, count); return 0; }这里使用fgetc逐个读取字符直到文件末尾。返回值赋给 int 类型变量是为了能正确判断 EOF避免 char 类型在部分平台上的符号问题。5.3 编译并运行先准备一个示例文本文件echo hello loongarch sample.txt然后交叉编译并运行loongarch64-linux-gnu-gcc -static -o count_chars count_chars.c qemu-loongarch64 ./count_chars sample.txt预期输出chars: 16为什么是 16因为hello有 5 个字符空格 1 个loongarch有 9 个字符echo写入时自带一个换行符加起来正好是 16。这个结果能说明两点程序正确读取了文件内容QEMU 模拟的 LoongArch 环境下标准库文件操作和系统调用能够正常工作。5.4 动态编译与 sysroot 说明如果去掉-static编译命令变成loongarch64-linux-gnu-gcc -o count_chars_dyn count_chars.c运行动态链接版本时QEMU 用户态模拟器需要找到 LoongArch 版本的动态链接器和共享库通常需要指定-L参数qemu-loongarch64 -L /usr/loongarch64-linux-gnu ./count_chars_dyn sample.txt不同发行版安装交叉 libc 的位置不同所以-L的值需要按实际环境调整。这也是我推荐先使用静态链接的原因可以把环境变量和路径问题暂时隔离掉。在实际项目中动态链接更贴近生产环境能显著减小二进制体积。但本地快速验证时静态编译是排查问题的最短路径。5.5 更进一步从用户态模拟到整机模拟QEMU 用户态模拟可以执行单个 LoongArch 程序但如果你想验证内核启动、驱动加载、系统服务就需要使用qemu-system-loongarch64配合内核镜像和根文件系统。这个方向偏系统级适配适合对内核和虚拟化熟悉的开发者。我的建议是先跑通用户态模拟再逐步深入整机模拟避免一次性引入太多变量。6. 常见问题与排查思路6.1 高频问题速查问题现象常见原因解决思路qemu-loongarch64命令不存在未安装 qemu-user-static或 PATH 未包含该命令安装 qemu-user-static确认命令路径出现Exec format error在 x86 主机上直接执行 LoongArch 可执行文件使用qemu-loongarch64 ./程序名运行动态编译后提示找不到动态链接器没有用-L指定交叉 lib 路径改用静态编译或补上正确的-L参数交叉编译时找不到头文件sysroot 缺失或路径不对安装对应的交叉 libc 开发包确认编译器前缀正确程序运行后输出乱码文本编码或终端字符集问题先排除文件内容编码再检查终端编码QEMU 运行崩溃模拟器版本与目标 ABI 不匹配升级 QEMU确认使用的是 LoongArch 目标支持6.2 一般排查步骤遇到问题先不要急着换编译器。按下面的顺序检查用file查看可执行文件的架构信息确认它是 LoongArch 还是 x86用ldd或readelf -d查看动态链接器路径确认运行命令是否带了qemu-loongarch64前缀确认交叉编译时使用的头文件和库文件属于同一套 sysroot查看 QEMU 版本是否支持当前 LoongArch ABI。这套检查顺序能覆盖绝大多数“编译通过但跑不起来”的情况。6.3 如何避免再次踩坑建议把交叉编译环境做成可复用的脚本或容器镜像记录编译器版本、QEMU 版本、sysroot 路径。这样换一台新机器时可以直接复原环境而不是靠记忆重新配置。还要定期关注 QEMU 和工具链版本更新因为龙架构生态迭代速度快旧版本可能不支持新指令或新 ABI。7. 最佳实践与工程建议7.1 用双周会驱动学习每期双周会内容都很多新手最容易犯的错误是“全都要学”。更现实的做法是每期只给自己定一个具体目标比如“这期只关注内核启动相关议题”其他部分先跳过。你可以用下面的表格记录每期收获项目内容本期主题例如内核、工具链、虚拟化与我的项目相关例如是否影响编译参数新名词例如psABI、UEFI、ACPI后续行动项例如下周编译某个内核分支这样积累几期之后你会有自己的知识索引而不是收藏了一堆“看过就忘”的生肉视频。7.2 在 CI 中加入 LoongArch 验证如果你的项目需要保证在龙架构上可用建议在 CI 中加入交叉编译和 QEMU 模拟测试。比如每次提交代码后用loongarch64-linux-gnu-gcc编译项目再用qemu-loongarch64跑一遍单测。需要注意QEMU 模拟不能完全替代真机验证。QEMU 用户态模拟更接近“指令翻译”性能数据、缓存行为、多核并发行为都和真实龙芯 CPU 有差异。涉及性能调优或硬件相关功能时一定要在真机上复核。7.3 保持对生态信息的敏感度龙架构生态发展很快关注 Linux 内核 Release Notes、GCC Release Notes、Binutils、LLVM 对 LoongArch 支持的变更会比只看双周会更有连续性。ABI 或 psABI 一旦有修订影响的是所有编译产物和系统库这种信息值得优先关注。同时你要注意信息源的可信度。优先看官方提交记录、官方文档和社区邮件列表不要把自媒体解读当作最终依据。7.4 安全与生产环境建议交叉编译工具链一定要从官方源或可信渠道获取不要随意运行来源不明的二进制安装包尤其不要使用非授权的“绿色版”“破解版”工具。生产环境使用新工具链或新内核补丁前先在测试环境完整验证一遍包括启动、基本服务、回归测试。双周会里讨论的很多内容还处于开发状态不适合直接应用到生产环境。如果你想试用某个新功能应该单独拉分支测试而不是直接替换生产工具链。8. 总结与下一步学习路线这篇文章的核心动作可以归结为三件事理解龙架构双周会的结构学会有策略地消化“生肉”资源在本地搭建一套 LoongArch 交叉编译与 QEMU 模拟环境通过一个文件读写程序验证整个工具链闭环。下一步的学习路线我建议按照“从应用到底层”的顺序推进。先继续写几个标准 C 程序用 QEMU 跑通熟悉交叉编译的常见参数然后阅读 LoongArch 官方文档中的基础指令和 psABI 规范搞清楚函数调用时参数怎么传再尝试用 QEMU 整机模拟启动一个小型 Linux 内核理解系统引导和内核初始化过程最后如果条件允许在龙芯真机或开发板上做性能验证。如果你今天只有十分钟时间最值得做的事情是把第 4 节的 hello world 完整跑一遍。环境通了之后后面看双周会就有了参照物。那些“生肉”视频里讨论的每一个启动问题、每一个工具链变更都会在你自己的验证环境里找到对应点。技术学习不怕生肉怕的是手里没有工具只能被动等待别人投喂。