这个系列写到这里基础指令、寻址方式、栈帧这些都已经跑过不少例子了。接下来有个绕不开的问题程序规模一大就不能老是把所有函数堆在同一个.asm文件里。比较好的做法是把通用的数学计算、字符串处理、调试打印这些抽成独立的汇编库让主程序去链接、调用。这一篇就围绕 Linux x86_64 汇编如何组织并调用汇编静态库从 ABI 约定、extern/global符号机制、ar打包、链接顺序到完整示例代码一条线走下来。适合已经能写简单汇编程序、但对“多文件工程化”还没概念的读者看完应该能自己把函数拆出去编成库再拉回来用。1. 为什么要把汇编代码拆成库1.1 单文件模式的三个痛点前面练习阶段的程序都不大几十行到一个文件里勉强能看。但只要函数一多单文件模式立刻变得很难受。第一是编译时间每次改一个函数整个文件都要重新汇编哪怕其他函数一行没动第二是命名空间所有label都在同一个作用域里稍不小心就重复定义链接器报multiple definition的时候人都是懵的第三是复用性问题写过一次的字符串长度计算、十进制转字符串换一个程序想用只能复制粘贴改起来还得所有副本一起改。拆库之后每个函数一个.asm文件独立汇编成.o再打包成静态库。主程序只关心“哪里可以调”不关心函数怎么实现。想修库里的某个函数重新汇编那一个文件再打包就行其余文件都不用动。这不只是汇编的问题是所有语言工程化的基本思路汇编虽然底子老但工程习惯一样不能省。1.2 三种组织方式怎么选汇编代码要复用时常见有三种形态。第一种是直接把多个.o文件和主程序一起链接比如ld main.o math.o str.o -o app。这种方式最简单不需要额外工具但链接命令会越来越长而且即使主程序只用到了math.o里的一个函数整个math.o的代码也会被塞进可执行文件。第二种是打包成静态库.a。.a本质上就是用ar命令把多个.o文件捆在一起同时建一个符号索引。链接器在扫描静态库的时候只会从里面挑出能解决当前未定义符号的那些.o文件没用到的一律不拉进来。这个机制叫“惰性提取”是静态库能保持输出干净的关键。第三种是动态库.so运行时要加载器参与生成和链接方式都更复杂以后单独写一篇比较合适。这一篇先老老实实把静态库跑通理解了符号决议过程后面看动态库会轻松很多。三种方式的对比可以这样看方式代码形式链接时机可执行文件体积维护成本适用场景直接链对象文件多个 .o链接时全量加入偏大命令易膨胀临时性多文件静态库 .a归档的 .o 集合按需提取只含用到的代码中等通用工具集、内部库动态库 .so共享对象运行时加载很小较高系统库、频繁更新模块1.3 库函数的接口约定要先写清楚C 有头文件汇编没有编译器帮你做类型检查。所以“接口文档”只能靠自己维护。一个库函数对应哪几个参数、参数放哪些寄存器、返回值在哪个寄存器、它会破坏哪些寄存器这些信息如果不写清楚调用方迟早出错。我的习惯是在每个库源码文件的头部写一个注释块比如;---------------------------------------------------------- ; gcd(int64_t a, int64_t b) ; 参数: rdia, rsib ; 返回: rax gcd(|a|, |b|) ; 破坏: rax, rcx? rdx, rdi, rsi ; 涉及: 若干全局/局部符号 ;----------------------------------------------------------所有库文件都按这个格式写符号命名统一加前缀比如libstr_、libmath_避免将来和 C 库的符号撞车。这个前缀习惯一开始嫌繁琐等库多起来之后会感谢自己当初没偷懒。2. 库函数契约x86_64 调用约定里你必须守的几条2.1 参数寄存器与返回值Linux x86_64 上的调用约定是 System V AMD64 ABI。它规定了整数和指针参数按顺序放在rdi、rsi、rdx、rcx、r8、r9这 6 个寄存器里超过 6 个才压栈浮点参数用xmm0到xmm7。返回值整数放rax浮点放xmm0。这个规则对汇编内部调用同样有意义。你当然可以在自己的汇编库里发明一套自己的传参规则比如规定第一个参数放rbx、第二个放rcx只要调用方和库函数商量好就行。但一旦你想调用 C 库的printf或者反过来让 C 代码调用你的汇编函数就必须严格按 ABI 来。从写库的第一天起就按 ABI 走能省掉后面大量返工。参数和返回值的对应关系参数位置整数/指针浮点第1个rdixmm0第2个rsixmm1第3个rdxxmm2第4个rcxxmm3第5个r8xmm4第6个r9xmm5返回值raxxmm02.2 谁负责保护谁的寄存器调用约定里最容易被忽略的是寄存器保存规则。ABI 把通用寄存器分成了两类调用者保存caller-saved和被调用者保存callee-saved。调用者保存寄存器包括rax、rcx、rdx、rsi、rdi、r8~r11。也就是说库函数内部可以随便改这些寄存器不需要负责还原。如果你作为调用方在调用库函数之后还想用这些寄存器里的旧值就得自己提前保存通常是压栈。被调用者保存寄存器包括rbx、rbp、rsp和r12~r15。库函数如果要用到它们进入函数后必须先压栈保存原值返回前再恢复。否则调用方存得好好的数据一进库函数就稀里哗啦全变了这就是典型的“寄存器被踩”问题。拿生活里的事打比方这就像借东西。调用者保存寄存器是“临时便签”你借给别人别人用完撕掉重写你不能怪他被调用者保存寄存器是“私人物品”别人借走之后必须原样还回来。分清这两类写库函数才有边界感。2.3 栈对齐的 16 字节规则还有一个看不见摸不着但能让你 debug 到崩溃的规则在call指令执行之前rsp必须保持 16 字节对齐。为什么 16 字节因为大量 C 库内部函数会使用 SSE 指令像movaps这类指令要求内存地址按 16 字节对齐一旦不对齐直接触发段错误。这个规则对只调用自己汇编库的纯算术函数影响不大因为函数内部不调用其他函数栈对齐不齐它都不关心。但一旦库函数内部要调用printf或者主程序在调用库函数之后调printf栈对齐问题就会立刻暴露。典型的症状是程序可能在某个movaps指令上崩溃而且崩溃位置和你写的代码看不出任何关系。我自己的排查经验是在编写所有外部函数调用之前检查一下rsp的值是否满足rsp % 16 0。如果从函数入口压了rbp那么压栈前和压栈后的状态要心里有数。后面的实操例子会演示一个对齐安全的调用顺序。2.4 一个简化版的库开发规范整理一下一个 x86_64 汇编库的内部函数至少应该做到这么几点需要对外可见的符号必须在源码里写global否则链接器根本看不到它。遵循 ABI 的参数和返回值约定不要把自定义的传参规则带到公共接口上。如果使用被调用者保存寄存器rbx、rbp、r12~r15先压栈、返回前恢复。在call之前保持 16 字节栈对齐。64 位代码访问自己定义的数据尽量用 RIP 相对寻址也就是 NASM 里写default rel。3. 链接器视角静态库从打包到符号决议3.1 extern 与 global符号可见性的一体两面汇编里的global和extern是对应的。global表示当前源文件里的某个符号允许被其他文件引用extern表示当前源文件要用到某个在其他文件定义的符号。两者缺一个都会有问题。如果库函数源码里忘了写global gcd那么gcd符号仍然是当前目标文件的局部符号。链接器扫描它的时候这个符号进不了全局符号表。你在主程序里怎么extern gcd都没有用最后报undefined reference to gcd。反过来主程序里忘了写extern gcdNASM 会认为gcd是当前文件内部符号要么报错要么把它当成一个未定义数据符号链接阶段才开始报错。检查符号最好的工具是nm。它会把目标文件或库里的符号列出来。大写T表示全局文本符号小写t表示局部文本符号U表示未定义符号。例如$ nm main.o U gcd U max U printf U sum_array 0000000000000000 T main $ nm libcalc.a max.o: 0000000000000000 T max gcd.o: 0000000000000000 T gcd sum.o: 0000000000000000 T sum_array看到gcd在库里的标记是小写t那就说明源文件里漏了global。看到主程序里没有U gcd说明extern没写对。这个检查套路五分钟就能定位问题。3.2 ar 打包与符号索引把多个.o文件打包成.a最常用的是ar rcs。r表示若归档中已有同名文件则替换c表示创建归档时不输出多余提示s表示写入符号索引。符号索引相当于给链接器准备的目录没有它链接器只能靠蛮力扫描整个归档效率低而且某些实现会找不到符号。实际操作时ar rcs libcalc.a max.o gcd.o sum.o一条命令就够了。如果之后想往库里补一个新函数只要把新的.o加在命令最后ar rcs libcalc.a max.o gcd.o sum.o strlen.o查看归档里的成员可以用ar t libcalc.a看符号索引可以用nm -s libcalc.a。打包本身不涉及任何编译它只是把.o文件按特定格式归拢起来真正起作用的是链接阶段的符号提取机制。3.3 链接顺序与静态库的惰性提取静态库和直接链接.o最大的区别在于链接器对它的处理是“按需提取”。链接器从左到右扫描命令行上的输入文件维护一个“当前未定义符号集合”。当扫描到一个普通.o时会把它的所有代码和数据都纳入输出。当扫描到一个.a时只从里面抽出那些能解决当前未定义符号的成员.o。这个机制直接导致了一个经典坑库必须放在使用它的目标文件后面。下面这种写法通常没问题gcc -o demo main.o -L. -lcalc因为链接器先读到main.o发现里面缺gcd、max、sum_array之后再扫到libcalc.a就能精准提取三个gcd.o、max.o、sum.o。如果反过来gcc -o demo -L. -lcalc main.o链接器先读libcalc.a这时未定义符号集合还是空的它不会提取任何成员等读到main.o才发现缺符号但已经过了库的扫描机会于是报 undefined。这个“不回看”的机制坑过很多人。有循环依赖的两个库之间互相引用时要么调整顺序要么用-Wl,--start-group和-Wl,--end-group把一组库包起来让链接器反复扫描。3.4 直接链接 .o 和链接 .a 的实质差异直接链接ld main.o max.o gcd.o sum.o链接器对这四个.o一视同仁全部塞进输出文件。哪怕sum_array主程序根本没用它的机器码照样在最终可执行文件里占地方。静态库则没有这个问题它能做到“用多少取多少”这也是静态库最大的工程价值。还有一个不太明显的好处是链接命令的稳定性。库打包之后链接命令只需要写-lcalc不需要把几十个.o全部列出来。随着库的成员增加命令不会越变越长。团队协作时你只需要把.a文件给别人不需要把内部.o的依赖关系也交代一遍。4. 完整实操写一个算术库并从主程序调用4.1 目标与目录计划这一节我们用 NASM 从零写一个非常小的算术库libcalc.a包含三个函数max(int64_t a, int64_t b)返回较大值。gcd(int64_t a, int64_t b)辗转相除法求最大公约数。sum_array(const int64_t *arr, size_t n)对数组求和。主程序通过extern声明这三个函数调用后直接用printf输出结果。文件结构是这样的. ├── max.asm ├── gcd.asm ├── sum.asm ├── main.asm先写库再写主程序最后编译打包链接运行。这个顺序符合一个真实项目的推进路径。4.2 库源码max、gcd、sum_array 逐个拆解先看max.asm。这个函数非常简单但用到了条件移动指令cmovge一次比较就能选出较大值没有分支跳转代码紧凑; int64_t max(int64_t a, int64_t b) ; rdi a, rsi b ; 返回 rax default rel global max section .text max: mov rax, rsi cmp rdi, rsi cmovge rax, rdi ret先假设结果是rsi比较rdi和rsi之后如果rdi rsige是有符号比较就用rdi覆盖结果。注意这里必须用cmovge而不是cmovae因为参数类型是int64_t有符号整数比较用ge无符号比较才用ae。然后是gcd.asm稍微复杂一些。用辗转相除法核心是idiv指令; int64_t gcd(int64_t a, int64_t b) ; rdi a, rsi b ; 返回 rax default rel global gcd section .text gcd: .loop: test rsi, rsi jz .done mov rax, rdi cqo idiv rsi mov rdi, rsi mov rsi, rdx jmp .loop .done: mov rax, rdi ret几个点要说明。第一cqo的作用是把rax符号扩展到rdx:rax因为idiv做有符号除法时要求被除数是rdx:rax的 128 位组合。第二idiv rsi的余数会放到rdx商在rax。第三循环开始先测rsi是否为 0是 0 就直接把rdi作为结果返回这把gcd(a, 0) a的边界情况也顺带处理了。注意gcd内部使用了rdi、rsi、rax、rdx这些都是调用者保存寄存器不需要恢复所以函数没有压栈代码。最后是sum.asm。函数指针参数rdi长度参数rsi用循环累加; int64_t sum_array(const int64_t *arr, size_t n) ; rdi arr, rsi n ; 返回 rax default rel global sum_array section .text sum_array: xor eax, eax test rsi, rsi jz .done .loop: add rax, [rdi] add rdi, 8 dec rsi jnz .loop .done: ret先用xor eax, eax把累加器清零然后判断长度是否为 0避免空数组越界访问。每次循环读取[rdi]指向的 8 字节数据加到rax再把指针后移 8 字节。这里没有检查数组长度和指针合法性这是调用方的责任汇编库里不过度做防御性检查保持函数精简。4.3 主程序extern 声明与 printf 参数布局主程序main.asm要同时调用自定义库和 C 库的printf正好把这一篇的 ABI 知识全部用上default rel global main extern printf extern max extern gcd extern sum_array section .rodata fmt_max: db max(42, 100) %ld, 10, 0 fmt_gcd: db gcd(252, 105) %ld, 10, 0 fmt_sum: db sum(array) %ld, 10, 0 arr: dq 7, 12, 9, 5, 20 section .text main: push rbp mov rbp, rsp ; gcd(252, 105) mov rdi, 252 mov rsi, 105 call gcd mov rcx, rax lea rdi, [fmt_gcd] mov rsi, 252 mov rdx, 105 call printf ; max(42, 100) mov rdi, 42 mov rsi, 100 call max mov rcx, rax lea rdi, [fmt_max] mov rsi, 42 mov rdx, 100 call printf ; sum_array(arr, 5) lea rdi, [arr] mov rsi, 5 call sum_array mov rsi, rax lea rdi, [fmt_sum] call printf xor eax, eax pop rbp ret这里有一个非常容易犯的错printf的第四个参数放在rcx不是r8。很多人写惯了前三个参数到第四个就顺手用r8结果输出全是 0或者干脆崩溃。其实第四个整型参数就是rcxr8是第五个。上面代码在call gcd拿到返回值之后先放到rcx再依次设置rdi、rsi、rdx顺序一丝都不能乱。还有一个细节lea rdi, [fmt_gcd]这种形式。因为源文件开头写了default relNASM 会把lea rdi, [fmt_gcd]生成 RIP 相对寻址这在现代 Linux 默认开启 PIE 的情况下是安全的。如果没有default rel写成mov rdi, fmt_gcd很可能会在链接或运行时栽跟头后面问题排查章节会展开讲。关于栈对齐main入口处push rbp之后rsp已经满足 16 字节对齐因此调用printf前不需要额外sub rsp。如果函数里还有更多局部变量需要栈空间就要自己计算调整量保证在每次call之前恢复对齐状态。4.4 编译、打包、链接、运行全流程先把三个库源码汇编成目标文件nasm -f elf64 -g -F dwarf -o max.o max.asm nasm -f elf64 -g -F dwarf -o gcd.o gcd.asm nasm -f elf64 -g -F dwarf -o sum.o sum.asm-f elf64指定 64 位 ELF 目标文件-g -F dwarf生成 DWARF 调试信息后面用 GDB 看代码会方便很多。打静态库ar rcs libcalc.a max.o gcd.o sum.o再汇编主程序并链接生成可执行文件nasm -f elf64 -g -F dwarf -o main.o main.asm gcc -o demo main.o -L. -lcalc注意这里用的是-L. -lcalc让链接器在当前目录找libcalc.a。如果没有-L.会报cannot find -lcalc。也可以直接写gcc -o demo main.o libcalc.a效果一样。运行$ ./demo max(42, 100) 100 gcd(252, 105) 21 sum(array) 537 12 9 5 20 正好是 53三个函数的结果都对。此刻再回头看nm的输出主程序里的U gcd、U max、U sum_array已经被链接器解析完毕而库文件中没被用到的符号不会出现在最终可执行文件里。4.5 不依赖 C 库的另一种主程序前面的示例为了输出方便调用了printf所以链接时必须经过 C 运行时初始化入口是main由系统库负责初始化栈和标准 IO。如果你希望整个程序完全不依赖 C 库只想验证静态库可以写一个极简入口_start把库函数的返回值作为进程退出码default rel global _start extern gcd section .text _start: mov rdi, 252 mov rsi, 105 call gcd mov rdi, rax mov rax, 60 syscall汇编后直接链接nasm -f elf64 -o main2.o main2.asm ld -o demo2 main2.o libcalc.a运行后用echo $?查看退出码$ ./demo2 $ echo $? 21这种方式展示的是“纯汇编调纯汇编静态库”的最小路径没有中间任何一层 C 库参与。也解释了为什么很多入门教程里_start可以直接用ld链接而一旦调用printf就必须用gcc或手动链接 C 运行时。两条路都值得跑一遍感受会很不一样。5. 常见问题与排查技巧实录5.1 undefined reference四个高频原因链接器报undefined reference to xxx是汇编库调用里最常见的错误。我总结了四个高频原因。第一库源文件里漏了global xxx符号变成局部符号链接器扫描时看不到第二主程序里漏了extern xxxNASM 可能直接报错也可能把符号当成数据引用等到链接期才爆出来第三库写在目标文件前面链接器扫描时还没产生未定义符号不会从库里提取内容第四符号名拼写不一致比如库文件导出的是gcd主程序却写了gdc。排查思路很简单先用nm看两个方向。主程序这边看有没有对应的U 符号库那边看有没有大写T 符号。只要两头都有链接器还不满意那大概率是顺序问题调整命令行顺序即可。5.2 找不到 -lcalc 与普通目标文件的区别报错长这样/usr/bin/ld: cannot find -lcalc原因只有一个链接器在默认搜索路径里没找到libcalc.a。注意-lcalc对应的文件名必须是libcalc.a前面必须有lib前缀后缀必须是.a。文件名叫calc.a或者libcalc.a不在-L指定的路径下都会失败。在当前目录下用-L.显式指定路径gcc -o demo main.o -L. -lcalc也可以完全绕开-l机制直接写归档文件全名libcalc.a。这样做的优点是路径一目了然缺点是一旦库数量变多命令会显得繁琐。正式项目通常用-L加-l的方式配合 Makefile 或构建脚本管理。5.3 一运行就崩PIE、绝对寻址与 default rel64 位 Linux 发行版普遍默认开启 PIE位置无关可执行文件。PIE 意味着可执行文件的加载地址在运行时才确定任何对全局数据符号的“绝对地址”访问都可能失效。NASM 默认情况下访问fmt_gcd这样的标签会生成绝对地址形式在 PIE 里链接时可能报类似“relocation truncated to fit”的错误也可能链接通过但一运行就段错误。解决办法有两个方向。一个是汇编代码里养成写default rel的习惯这样lea rdi, [fmt_gcd]会生成 RIP 相对寻址天然兼容 PIE。另一个是链接时关掉 PIEgcc -no-pie -o demo main.o -L. -lcalc-no-pie后绝对地址也成立但这会削弱 ASLR 对代码段随机化的保护。我的建议是代码里务必写default rel而不是依赖关闭 PIE 来救场毕竟库本身将来可能被其他程序以 PIE 方式链接。5.4 printf 输出异常参数寄存器与格式串不匹配如果printf输出乱码、输出 0、或者输出一个天文数字多半是参数寄存器和格式串没对上。举两个最常见的例子。第一个是按%d输出 64 位整数printf只从寄存器低 32 位取值导致高位被忽略得到莫名其妙的结果。64 位值要配%ld或%lld。第二个是第四个参数放在了r8但 ABI 规定第四个整型参数是rcxr8是第五个。看起来只是换一个寄存器结果完全不同。还有一种隐蔽情况是调用printf前rsp没有 16 字节对齐。printf内部会使用 SSE 指令不对齐就直接段错误。这类崩溃不在printf那一行报错而是在 glibc 内部的某个movaps指令上崩掉反汇编看调用栈才能发现端倪。5.5 排查工具箱与个人习惯最后分享几个我常用的调试命令都是系统自带工具不像 GDB 那么重但很能解决问题。nm -s libcalc.a看静态库符号索引objdump -d gcd.o看库函数反汇编确认指令生成是否符合预期readelf -h main.o看目标文件类型和架构防止elf32和elf64混用ldd demo看可执行文件依赖的动态库排查链接阶段是否意外引入了奇怪依赖gdb用于打断点单步调试比如break gcd后执行run能直观看到参数进入库函数时的寄存器状态。我个人排查汇编库问题时有个习惯先符号后指令再数据。先用nm确认符号两头都通再用objdump看关键函数的前几条指令比如有没有生成 RIP 相对寻址、有没有该压栈的寄存器没压。符号层面没问题了再进 GDB 看运行时数据。这个顺序能过滤掉大部分低级错误剩下真正需要断点调试的往往就是逻辑问题了。
