go tool compile -s 输出函数级plan 9风格汇编,含源码行号和变量信息,用于调试与性能分析;需配合-l -m观察内联、逃逸等优化,且不生成可链接的汇编文件。

用 go tool compile -S 看函数级汇编
Go 编译器(gc)本身不生成独立的汇编文件供链接器直接使用,但能输出人类可读的、带源码注释的汇编清单——这是调试和性能分析最常用的方式。
关键命令是:go tool compile -S main.go。它默认输出到终端,显示每个函数的 SSA 中间表示之后生成的最终目标平台汇编(如 AMD64 指令),并穿插 Go 源码行号和变量信息。
-
-S必须小写;大写-s是关闭符号表,完全无关 - 若源文件有 import,需确保
GOOS/GOARCH环境变量与目标一致(比如交叉编译时加GOARCH=arm64 go tool compile -S main.go) - 输出里看到的
CALL runtime.printint这类调用不是“系统调用”,而是 Go 运行时内部函数,别误以为是 libc
用 go build -gcflags="-S" 编译整个包并保留临时文件
单文件 go tool compile 不处理依赖解析,遇到 import 容易报错。更稳妥的做法是走完整构建流程,让 go build 自动管理依赖,再通过 -gcflags 注入汇编输出开关。
执行:go build -gcflags="-S -S" main.go(重复两次 -S 会显示更详细的 SSA 阶段信息,第一次只显示最终汇编)。
初始化并管理阿里云SDK Go 客户端,涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 加
-o /dev/null可避免生成二进制,纯看汇编:go build -gcflags="-S" -o /dev/null main.go - 想限制只看某个函数?用
-gcflags="-S -l" -gcflags="-m=2"组合可定位内联行为,但-S本身不支持函数过滤,得靠 grep:go build -gcflags="-S" main.go 2>&1 | grep -A20 "funcName$" - 注意:
-S输出的是“伪汇编”(plan9 syntax),不是 GNU as 能直接吃的 AT&T 或 Intel 语法,别试图拿去用as汇编
生成真正可汇编的 .s 文件?得用 go tool asm 配合手写
Go 官方不提供从 Go 源码自动生成标准 NASM/GAS 格式汇编文件的功能。所谓“编译成汇编”,绝大多数场景下指的就是上面两种查看方式。
如果你真需要一个 .s 文件参与链接(比如混写汇编优化热点),必须手动写,然后用 go tool asm 编译:
- 文件名必须是
xxx_amd64.s(后缀含平台标识),且首行加//go:build amd64 - 语法是 Plan 9 汇编(寄存器名前无 %,立即数前有 $,跳转目标无冒号),例如:
MOVQ $1, AX - 调用 Go 函数要加前导点:
CALL ·add(SB);导出给 Go 调用的函数需用TEXT ·add(SB), NOSPLIT, $0-24 -
go tool asm -o add.o add_amd64.s生成目标文件,再由go tool link链入,不能直接用gcc或ld
为什么看不到熟悉的 main 入口或 libc 调用?
Go 程序启动链和 C 完全不同:runtime.rt0_go → runtime._rt0_amd64 → runtime.main,没有 _start 或 main 符号暴露给系统 loader。所有系统调用都经由 runtime.syscall 或 runtime.entersyscall 封装,底层用 SYSCALL 指令而非 call libc。
- 在
-S输出里搜SYSCALL才能看到真正的系统调用点,比如write系统调用对应MOVQ $1, AX; SYSCALL -
println、fmt.Println这类不会直接变成printf调用,而是走 Go 自己的 I/O 缓冲和 write 系统调用 - 想确认某段代码是否被内联?加
-gcflags="-m=2",比盯着汇编更快
真正要动手改汇编,基本只发生在 runtime 包或极端性能敏感的数学库中;日常看 -S 输出,重点不是记指令,而是验证编译器有没有按预期优化分支、消除冗余内存访问、保持寄存器局部性——这些信号藏在指令密度和寄存器使用模式里,而不是语法本身。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!










