去年底我陆续面完了PLCT实验室的几个方向其中oerv这条线聊得最深前后经历了简历初筛、电话沟通、线上笔试、两轮技术面试前前后后跨了两周多。过程踩了不少坑也把面试官追问过的知识点复盘了好几遍。这篇东西就是把这些经历整理成一份参考重点说清楚oerv到底在做什么、面试会怎么考、考察重点是什么以及你该往哪个方向准备。对RISC-V工具链、软件包移植、Linux发行版适配感兴趣的朋友这份面经应该能帮你在面试前省下不少弯路。1. 先搞清楚你到底在投什么PLCT实验室与oerv的真实面貌1.1 PLCT实验室不是那种“写业务代码”的地方PLCT实验室全称是Programming Language and Compiler Technology Lab主要精力放在编译器、虚拟机、二进制翻译、RISC-V软件生态这些偏底层的方向上。跟普通互联网公司的后端开发岗不同这里的很多工作产出是patch、issue、spec文件、工具链报告而不是上线一个功能页面。面试官更在意你对底层原理的理解深度以及你动手折腾过多少真实问题。我自己被问到的第一个问题就是“你平时有没有给开源社区提过patch”这个问题背后其实是在确认你有没有真正的开源协作经验而不只是用过GitHub、知道git commit那几条命令。PLCT的工作很大比例是跟上游社区打交道代码要走mailing list、code review、CI修复、格式检查这一整套流程跟自己在本地开发完全是两码事。1.2 oerv在openEuler生态里的角色oerv就是openEuler RISC-V的缩写。openEuler原本主要是x86和AArch64架构的发行版oerv这个项目要做的事情是把openEuler完整地移植到RISC-V架构上让大量软件包能在riscv64环境下正常编译、安装、运行。这不像听起来那么轻松。RISC-V虽然指令集是开放的但整个软件生态跟x86/AArch64比还差很远。很多软件包在x86上直接./configure make make install就过了到了riscv64上会冒出各种问题——汇编代码不支持、autoconf检测不到架构、链接时缺少某个库的riscv64版本、JIT类软件没有riscv64后端的支持等等。oerv的工作就是逐一把这些包啃下来让openEuler RISC-V变成一个真正可用的发行版。1.3 岗位方向选型编译器、软件包移植还是系统测试我在投递时列了软件包移植和维护方向但这背后其实有个更大的问题你更适合哪个环节。PLCT的oerv相关工作大体可以分成几条线软件包编译与依赖修复处理spec文件、解决构建失败、打补丁适配riscv64。工具链与编译器涉及gcc、binutils、glibc对RISC-V的支持以及qemu、llvm等运行时的适配。镜像构建与集成负责生成可启动的openEuler RISC-V镜像涉及内核、rootfs、引导、驱动等。质量保障与测试跑测试套件、报告失败用例、分析回归。面试前我建议你先想清楚自己更适合哪条线。因为不同方向的技术问题差异很大比如偏编译的方向会更深地考gcc的RTL、内联汇编、ABI偏移植的方向则会频繁考依赖关系、链接过程、patching的技巧。我自己投的是软件包移植方向面试内容也基本围绕这个展开所以下面几个部分会以这个方向为主线来讲。2. 简历写完只是开始面试前必须盘清楚的技术栈2.1 RISC-V架构高频考点从指令集到ABIoerv面试绕不开RISC-V基础面试官会从你最熟悉的点开始一路往下刨。比如你会不会从“RISC-V有哪些基本扩展”开始答然后被问到“RV64GC具体包含哪些子集”“LP64D是什么意思”“为什么ILP32和LP64要分这么细”。这些概念看起来基础但很多人其实只是背了缩写没搞清楚背后的实用性。我简单梳理一下常考的点RV32和RV64区分基础指令是32位还是64位RV64的通用寄存器是64位。I、M、A、F、D、C子集I是整数指令M是乘除法A是原子指令F是单精度浮点D是双精度浮点C是压缩指令。G其实是个组合指IMAFD这套常用组合。ABI与指令集的关系LP64D表示长整型是64位、浮点用双精度硬浮点传递ILP32表示long和指针都是32位。选错ABI在编译时就会出现“找不到libc库”之类的问题。特权级别U-Mode、S-Mode、M-Mode分别对应应用态、内核态、机器态。RISC-V的SBI和M-Mode固件之间的关系通常也是追问点。我当时被问到“RV64GC的G到底代表什么”时一开始只说是General后来面试官继续问“那LMUL在RVV里是什么和General有关系吗”我才意识到他其实是想考察我对自己写过的名词是否真的理解。如果你在简历里写了某个指令集扩展那么它背后对应的寄存器、数据通路语义一定要能解释清楚。2.2 构建链路是oerv的主战场rpmbuild、spec、OBS因为oerv和openEuler直接相关所以面试很少绕开rpmbuild这套流程。openEuler的软件包基本都以RPM形式组织每个软件包由一个spec文件描述如何下载源码、打补丁、配置编译、安装产物。RISC-V移植的工作很多时候就是在改spec新增一个条件判断、在%prep阶段打上riscv64补丁、或者调整%check里的测试项。面试官问我的一个核心问题是“如果openEuler里一个软件包在x86上构建成功但在riscv64上失败了你会怎么排查”这个问题特别开放但踩点很清晰先看构建日志报错的位置判断是配置阶段失败、编译失败还是链接失败。配置阶段失败大概率是autoconf的config.guess不认识riscv64或者某个依赖库没有安装对应riscv64版本。编译阶段失败通常是内联汇编、SSE等x86专属指令、或者类型宽度假设导致。链接阶段失败一般是某个静态库或动态库没有构建出riscv64版本也可能是链接脚本或ldflags指定了x86路径。除了单个软件包的构建OBSOpen Build Service也是必须知道的。openEuler许多包的构建是在OBS上做的oerv的任务之一就是在OBS上扩展riscv64的构建目标。如果面试中能说出osc客户端怎么提交包、怎么解决project config里的Architecture限制、怎么在本地用osc build复现构建失败印象分会明显提升。2.3 开源协作能力不要只说“我提过issue”PLCT的活很多要跟上游协同所以面试还特别关注你处理patch、review和反馈的耐心和细致程度。我准备的思路其实只有一句话别说你用过GitHub要说出你从fork到提交PR再到被review又修改的完整闭环。一般流程是在Gitee/GitHub上fork对应仓库创建自己的分支。修改代码或spec文件保持改动尽量小、单一。提交时写清楚commit message说明问题背景、修改方式和测试结果。发起PR/补丁在描述里贴出构建日志方便reviewer快速复现。收到review意见后逐条回应必要时更新补丁并重新跑CI。面试官会追一些细节比如“如果上游已经很久不回应你的patch你会怎么做”。这时候别只说“发邮件催”更合理的做法是检查patch是否基于最新master生成、有没有按照上游的贡献规范调整格式再去mailing list或issue里礼貌跟进附上新的构建结果。3. 电话面、笔试和面试官追问真实面试流程复盘3.1 初筛和电话沟通时间不长问题不浅我的初筛是一通电话大概半小时。对方先确认了基本信息然后很快就切到技术问题上问了我什么是RISC-V的SBI、openEuler RISC-V的镜像跑在什么硬件上、有没有实际跑过开发板。这里有个经验不要对电话面掉以轻心因为对方很可能在大海捞针地筛掉对RISC-V完全没有概念的人。我当时还问了面试官一个比较“新手”的问题“oerv是不是主要做镜像下载链接的维护”面试官愣了一下然后温和地解释说是要处理大量软件包的riscv64适配。这个经历挺尴尬的但也提醒我面试前一定要把项目的真实形态了解清楚否则很容易给人“就看了个名字就来投”的感觉。3.2 笔试环节没有算法题全是场景题笔试没有走LeetCode题海路线而是给了一套偏实际场景的题目。包括给出一段构建日志要求判断是哪个阶段失败并写出排查思路。给出一段C代码要求指出它在riscv64和x86_64上行为可能不同的地方。要求写一个shell脚本或Python脚本用来批量检查一批软件包的构建状态。询问如果要为oerv新增一个软件包的riscv64支持你会提交哪些文件每个文件的作用是什么。其中第三题比较有意思考察的是自动化能力。我用了Python加requests库去调OBS的API按项目名过滤出失败状态的包再汇总成表格。面试官后来反馈说这道题能看出候选人是不是真的能应对大规模软件包适配的场景因为手动一个个点网页在oerv这种量级下根本不现实。3.3 技术面试的追问逻辑从你写过的内容出发两轮技术面试的共同特点是从简历内容出发深挖。你在简历里写“熟悉Linux系统”面试官可能就会问你用的是什么发行版启动一个服务时systemd的unit文件怎么写的怎么看一个程序依赖哪些动态库动态库搜索路径的顺序是怎样的如果某个库文件缺失用什么命令找到它由哪个包提供这些问题本身不难但每一层往下的“为什么”都会让人有点压力。例如我答到“用ldd查看动态库依赖”之后面试官问“ldd到底做了什么它为什么不直接告诉你缺哪个包而是打印not found”我才意识到自己平时只是会用没有深入看它的实现机制。还有一次面试官用了一个很简单的例子让我临场分析为什么同一个程序在x86上可以运行交叉编译到riscv64后打开就报“No such file or directory”。我没有往动态链接器方向想只想到文件缺失。面试官点了一下说是不是interpreter路径不对。这个知识点其实就是readelf -l输出中ELF interpreter那段x86的通常是/lib64/ld-linux-x86-64.so.2riscv64则是/lib/ld-linux-riscv64-lp64d.so.1如果文件系统里没有对应解释器内核启动程序时就会报那个错误。这说明oerv面试考察的不只是RISC-V特有知识点而是Linux系统层面的底层机制。如果只背指令集定义不熟悉链接、加载、动态库机制很容易答到一半卡壳。4. 高频面试题拆解从答题思路到参考答案4.1 RISC-V特权架构和A/B扩展名别背缩写理解设计目标面试官非常喜欢问特权架构可能因为PLCT大量工作涉及SBI、OpenSBI、内核启动等环节。你需要把M-Mode、S-Mode、U-Mode的关系和各自职责讲清楚M-Mode是机器态拥有最高权限OpenSBI这类固件跑在这里。S-Mode是内核态Linux内核跑在这里。U-Mode是应用态普通用户进程跑在这里。追问常见的是“如果用户程序想访问某个硬件资源Linux内核和SBI分别扮演什么角色”答案是用户程序通过系统调用陷入内核内核如果需要操作硬件再通过SBI调用进入M-Mode由OpenSBI的运行时服务来执行实际操作。这样分层的好处是让内核只要按SBI规范调用接口不必关心具体硬件平台差异。A扩展和B扩展也经常被提到。A扩展对应原子指令比如lr.w/sc.w、amo*.x等在多核同步和无锁编程里至关重要。B扩展是位操作指令包含andn、orn、rol/ror、clz、ctz等能提升某些场景的代码密度和性能。但要注意B扩展还没有完全冻结不同工具链版本对它的支持程度可能不一样面试时如果能顺带提一句“所以我编译时会确认-march里是否包含zbb、zba这些子集”会显得你很了解工具链现状。4.2 编译适配实战题从“编译失败”倒推根因这一块是oerv面试的重头戏。常见问法是给出一个软件在riscv64上构建失败的样例让你分析如何处理。比如一段在configure阶段出错的日志checking for C compiler default output file name... configure: error: cannot compute C compiler default output file name如果完整日志里还包含“/usr/bin/ld: skipping incompatible ... when searching for -lc”这类信息那么十有八九是编译器本身或文件系统里装了x86版本的库而不是源码问题。更常见的还有这三种情况源码里用到了x86内联汇编比如__asm__(bswap %0 : r(x))这种在riscv64上根本无法编译需要改写为通用C代码或调用编译器内建函数。源码中有x86风格的对齐假设比如把结构体指针强转为uint64_t再加减这在strict aliasing下本身就危险在riscv64上更明显。源码缺失对riscv64的宏判断比如#error unsupported architecture需要补上对应的宏分支。答题的时候如果能按“先看architecture判断再看编译阶段再查依赖”这个思路走面试官就认为你具备适配工作的基本逻辑。这个顺序很关键因为很多时候编译失败其实不是当前包的问题而是依赖链上某个库没适配好。4.3 调试手段和常见踩坑案例qemu-user、gdb、readelfoerv面试里肯定会涉及调试因为软件包移植最终要落到“你能不能复现问题、定位问题”。最常用的路径是用qemu-riscv64配合gdb做用户态调试先在模拟器里复现问题再比对寄存器状态和内存布局。用qemu-system-riscv64跑完整系统镜像用于验证启动流程、内核模块加载、设备驱动等多方面问题。用readelf查看ELF文件头、程序头表、动态段确认目标程序是否真的是riscv64以及interpreter路径是否正确。用objdump反汇编定位crash地址附近的具体指令。有一个实际案例我印象很深某个包在riscv64的qemu-user下运行正常但放到真机上就会段错误。排查后发现qemu-user模式下fork和mman的默认行为跟真机略有不同导致程序对某块缓存的初始化路径没有被触发。后来加上正常的测试用例减少对环境的依赖才真正定位是源码中对cacheline对齐的假设和RISC-V的CMO扩展实现不一致。这类经验在面试中讲出来会明显提升说服力。5. 面完复盘那些我没答好和面试官没说出口的潜规则5.1 我在实际复盘时发现的最关键三个短板整个流程结束后我按面试记录做了复盘最明显的短板是以下三个第一我在x86领域积累的“条件反射”在RISC-V上不一定适用。比如用-marchnative在x86上很方便但在riscv64交叉编译时这是个大坑。native选项会让编译器探测宿主机的本地架构交叉编译时根本不该用这个选项应该明确指定目标架构比如-marchrv64gc -mabilp64d。第二我对动态链接机制在riscv64上的差异了解不够细特别是关于合入库和interpreter的关系。readelf -l输出里那一行interpreter非常重要一旦动态链接器路径不对程序一旦启动就会出现“No such file or directory”这种误导性的错误。这个坑在oerv日常适配当中只多不少。第三我对“如何证明一个包已经适配成功”的思考不够完整。面试官会问“如果一个包在riscv64上构建成功了你敢说它一定能用吗”从工程角度来说构建成功只是第一步还需要在目标架构上确认单元测试或基础功能是否正常。如果包的测试套件本身不支持riscv64可以直接记录并报告而不是当作成功。5.2 面试官到底在找什么样的人根据对面两轮面试官的提问风格我总结下来oerv需要的候选人是这样的画像对RISC-V指令集、Linux系统底层、构建链路有真实兴趣不是只看过新闻。有实打实处理过软件包或工具链问题的经验哪怕是在自己电脑上折腾出来的。能接受相对琐碎但重要的工作比如修复一类一类的编译错误、跟踪具体软件包的依赖关系。遇到问题时不急于乱试而是先理解构建阶段、日志特征和根因再动手修复。面试官没有直接说“我们不要只会背概念的人”但问的问题处处都在筛选这类人。所以如果你在准备面试比起背几十条RISC-V指令不如好好把一个软件包从源码构建到riscv64真机上运行起来的全链路走通一遍。5.3 给后来者的实用准备路线如果我从头准备一次我会按照下面这条路线来推进你也可以参考先在能联网的x86环境上安装openEuler或Fedora练习rpmbuild的基础操作弄清spec文件各个段落的作用。用QEMU跑一个openEuler RISC-V的镜像熟悉riscv64环境下的shell操作、软件安装和日志查看。选一个相对简单的软件包手动在riscv64的QEMU里源码编译一遍记录下遇到的每一个错误和解决方案。这比只看别人写的适配笔记有用得多。学会用osc和OBS尝试往openEuler的某个项目里提交一个riscv64构建测试搞清楚project config和package meta的关系。阅读openEuler RISC-V相关的issue列表挑一两个自己能看懂的尝试基于上游最新代码复现问题并给出分析。准备周期其实不用太长如果每天能抽出两三个小时持续两三周就足够建立对整个流程的基本感觉。重点是把每一步动手落实因为面试官问“你遇到过什么坑”时你不需要背答案只需要讲出真实的经历。最后再分享一个我自己的体会oerv这类开源移植项目的面试本质上是在考“你能不能在一个并不完美的生态里把一件很基础但很关键的事情做扎实”。这种能力很难靠短期刷题获得但如果你真的花时间在QEMU里把某个包从编译失败调到运行成功面试时你会自然散发出一股“我确实干过这个”的底气。祝准备投递的朋友都能顺利。