「cgo 不是银弹」，cgo 是连接 Go 与 C （乃至其他任何语言）之间的桥梁。 cgo 性能远不及原生 Go 程序的性能，执行一个 cgo 调用的代价很大。 下图展示了 cgo, go, c 之间的性能差异（网络 I/O 场景）：
第十章 10.4 cgo - 图1 图1: cgo/Go/C/net 包 在网络 I/O 场景下的性能对比，图取自 github.com/changkun/cgo-benchmarks
本文则具体研究 cgo 在运行时中的实现方式。

入口

先来编写一个最简单的 cgo 程序：
package main

/
#include “stdio.h”
void print() {
printf(“hellow, cgo”);
}
/
import “C”

func main() {
C.print()
}
我们先观察一下汇编的结果：
TEXT main._Cfunc_print(SB) _cgo_gotypes.go
_cgo_gotypes.go:40 0x40503c0 65488b0c2530000000 MOVQ GS:0x30, CX
(…)
_cgo_gotypes.go:41 0x40503e7 488b053aca0600 MOVQ main._cgo_fd63072f180f_Cfunc_print(SB), AX
_cgo_gotypes.go:41 0x40503ee 48890424 MOVQ AX, 0(SP)
_cgo_gotypes.go:41 0x40503f2 488b442418 MOVQ 0x18(SP), AX
_cgo_gotypes.go:41 0x40503f7 4889442408 MOVQ AX, 0x8(SP)
_cgo_gotypes.go:41 0x40503fc e8ff3bfbff CALL runtime.cgocall(SB)
(…)

TEXT main.main(SB) /Users/changkun/dev/go-under-the-hood/demo/10-cgo/main.go
main.go:11 0x4050420 65488b0c2530000000 MOVQ GS:0x30, CX
(…)
main.go:12 0x405043b e880ffffff CALL main._Cfunc_print(SB)
(…)
说明 Go 代码在进入 C 代码前，最终以用编译器配合的形式，进入了运行时的 runtime.cgocall。
再来看一下整个编译过程中的临时文件，临时文件中的入口文件为 main.cgo1.go：
// Code generated by cmd/cgo; DO NOT EDIT.

//line main.go:1:1
package main

/
#include “stdio.h”
void print() {
printf(“hellow, cgo”);
}
/
import _ “unsafe”

func main() {
(_Cfunc_print)()
}
可以看到 Go 编译器会将我们原有的 cgo 调用替换为：_Cfunc_print。 我们可以在 _cgo_gotypes.go 中看到这个函数的定义：
//go:cgo_unsafe_args
func _Cfunc_print() (r1 _Ctype_void) {
// 调用 _cgo_runtime_cgocall 传递 C 函数的入口地址以及相关参数
_cgo_runtime_cgocall(_cgo_222b4724d882_Cfunc_print, uintptr(unsafe.Pointer(&r1)))
if _Cgo_always_false {
}
return
}
而 _cgo_runtime_cgocall 的定义：
//go:linkname _cgo_runtime_cgocall runtime.cgocall
func _cgo_runtime_cgocall(unsafe.Pointer, uintptr) int32
可以看到编译器通过编译标志 go:linkname 将这个调用链接为了 runtime.cgocall。 因此，从 Go 进入 C 空间的 cgo 调用，以 Go 程序为主体（运行时依然存在），通过编译器的配合， 当需要调用 C 代码时，会向运行时传递 C 函数的入口地址及所需传递的参数。
那么剩下的工作就是去分析 runtime.cgocall 这个调用如何与 Go 运行时进行交互了。

cgocall

原理概述: Go 调用 C

从 Go 调用 C 函数 f，cgo 生成的代码会调用 runtime.cgocall(_cgo_Cfunc_f, frame), 其中 _cgo_Cfunc_f 为由 cgo 编写的并由 gcc 编译的函数。
runtime.cgocall 会调用 entersyscall（参见 syscall.*）， 从而不会阻塞其他 goroutine 或垃圾回收器 而后调用 runtime.asmcgocall(_cgo_Cfunc_f, frame)。
runtime.asmcgocall 会切换到 m.g0 栈(操作系统分配的栈，因此能安全的在运行 gcc 编译的代码) 并调用 _cgo_Cfunc_f(frame)。 _cgo_Cfunc_f 获取了帧结构中的参数，调用了实际的 C 函数 f，在帧中记录其结果， 并返回到 runtime.asmcgocall。 在重新获得控制权后，runtime.asmcgocall 会切换回原来的 g (m.curg) 的执行栈 并返回 runtime.cgocall。 在重新获得控制权后，runtime.cgocall 会调用 exitsyscall，并阻塞，直到该 m 运行能够在不与 $GOMAXPROCS 限制冲突的情况下运行 Go 代码。

  1. Go --> runtime.cgocall --> runtime.entersyscall --> runtime.asmcgocall --> _cgo_Cfunc_f
  2.                                                                                  |
  3.                                                                                  |
  4. Go <-- runtime.exitsyscall <-- runtime.cgocall <-- runtime.asmcgocall <----------+

实际代码

// 从 Go 调用 C
//go:nosplit
func cgocall(fn, arg unsafe.Pointer) int32 {
(…)

// 运行时会记录 cgo 调用的次数
mp := getg().m
mp.ncgocall++
mp.ncgo++

// 重置回溯信息
mp.cgoCallers[0] = 0

// 宣布正在进入系统调用，从而调度器会创建另一个 M 来运行 goroutine
//
// 对 asmcgocall 的调用保证了不会增加栈并且不分配内存，
// 因此在 $GOMAXPROCS 计数之外的 “系统调用内” 的调用是安全的。
//
// fn 可能会回调 Go 代码，这种情况下我们将退出系统调用来运行 Go 代码
//（可能增长栈），然后再重新进入系统调用来复用 entersyscall 保存的
// PC 和 SP 寄存器
entersyscall()

// 将 m 标记为正在 cgo
mp.incgo = true

// 进入调用
errno := asmcgocall(fn, arg)

// 在 exitsyscall 之前进行计数，因为 exitsyscall 可能会把
// 我们重新调度到不同的 M 中
//
// 取消运行 cgo 的标记
mp.incgo = false
// 正在进行的 cgo 数量减少
mp.ncgo—

// 宣告退出系统调用
exitsyscall()

(…)

// 宣告退出系统调用
exitsyscall()

// 从垃圾收集器的角度来看，时间可以按照上面的顺序向后移动。
// 如果对 Go 代码进行回调，GC 将在调用 asmcgocall 时能看到此函数。
// 当 Go 调用稍后返回到 C 时，系统调用 PC/SP 将被回滚并且 GC 在调用
// enteryscall 时看到此函数。通常情况下，fn 和 arg 将在 enteryscall 上运行
// 并在 asmcgocall 处死亡，因此如果时间向后移动，GC 会将这些参数视为已死，
// 然后生效。通过强制它们在这个时间中保持活跃来防止这些未死亡的参数崩溃。
KeepAlive(fn)
KeepAlive(arg)
KeepAlive(mp)

return errno
}

//go:noescape
func asmcgocall(fn, arg unsafe.Pointer) int32
从名字上我们可以看出 asmcgocall 是由汇编写成的：
// func asmcgocall(fn, arg unsafe.Pointer) int32
// 在调度器栈上调用 fn(arg), 已为 gcc ABI 对齐，见 cgocall.go
TEXT ·asmcgocall(SB),NOSPLIT,$0-20
MOVQ fn+0(FP), AX
MOVQ arg+8(FP), BX

MOVQ    SP, DX

// 考虑是否需要切换到 m.g0 栈<br />    // 也用来调用创建新的 OS 线程，这些线程已经在 m.g0 栈中了<br />    get_tls(CX)<br />    MOVQ    g(CX), R8<br />    CMPQ    R8, $0<br />    JEQ    nosave<br />    MOVQ    g_m(R8), R8<br />    MOVQ    m_g0(R8), SI<br />    MOVQ    g(CX), DI<br />    CMPQ    SI, DI<br />    JEQ    nosave<br />    MOVQ    m_gsignal(R8), SI<br />    CMPQ    SI, DI<br />    JEQ    nosave<br />    <br />    // 切换到系统栈<br />    MOVQ    m_g0(R8), SI<br />    CALL    gosave<>(SB)<br />    MOVQ    SI, g(CX)<br />    MOVQ    (g_sched+gobuf_sp)(SI), SP

// 于调度栈中（pthread 新创建的栈）<br />    // 确保有足够的空间给四个 stack-based fast-call 寄存器<br />    // 为使得 windows amd64 调用服务<br />    SUBQ    $64, SP<br />    ANDQ    $~15, SP    // 为 gcc ABI 对齐<br />    MOVQ    DI, 48(SP)    // 保存 g<br />    MOVQ    (g_stack+stack_hi)(DI), DI<br />    SUBQ    DX, DI<br />    MOVQ    DI, 40(SP)    // 保存栈深 (不能仅保存 SP, 因为栈可能在回调时被复制)<br />    MOVQ    BX, DI  // DI = AMD64 ABI 第一个参数<br />    MOVQ    BX, CX  // CX = Win64 第一个参数<br />    CALL    AX  // 调用 fn

// 恢复寄存器、 g、栈指针<br />    get_tls(CX)<br />    MOVQ    48(SP), DI<br />    MOVQ    (g_stack+stack_hi)(DI), SI<br />    SUBQ    40(SP), SI<br />    MOVQ    DI, g(CX)<br />    MOVQ    SI, SP

MOVL    AX, ret+16(FP)<br />    RET

nosave:
// 在系统栈上运行，可能没有 g
// 没有 g 的情况发生在线程创建中或线程结束中（比如 Solaris 平台上的 needm/dropm）
// 这段代码和上面类似，但没有保存和恢复 g，且没有考虑栈的移动问题（因为我们在系统栈上，而非 goroutine 栈）
// 如果已经在系统栈上，则上面的代码可被直接使用，但而后进入这段代码的情况非常少见的 Solaris 上。
// 使用这段代码来为所有 “已经在系统栈” 的调用进行服务，从而保持正确性。
SUBQ $64, SP
ANDQ $~15, SP // ABI 对齐
MOVQ $0, 48(SP) // 上面的代码保存了 g, 确保 debug 时可用
MOVQ DX, 40(SP) // 保存原始的栈指针
MOVQ BX, DI // DI = AMD64 ABI 第一个参数
MOVQ BX, CX // CX = Win64 第一个参数
CALL AX
MOVQ 40(SP), SI // 恢复原来的栈指针
MOVQ SI, SP
MOVL AX, ret+16(FP)
RET
在这段调用中本质上有两种情况：

  1. 不在系统栈上：这种情况下，由于 goroutine 栈的移动，判断当前是否在系统栈上，如果不在，则切换到系统栈上调用 C。
  2. 在系统栈上：无论是否有 g ，如果已经在系统栈上，所以保存现场不需要自行处理，因此进入 nosave 直接调用 C，当返回时会自行恢复现场。

    cgocallbackg

    本质上我们忽略了一个过程，如果一个调用是从 C 进入 Go 那么情况完全不一样。

    原理概述: C 调用 Go

    上面的描述跳过了当 gcc 编译的函数 f 调用回 Go 的情况。如果此类情况发生，则下面描述了 f 执行期间的调用过程。
    为了 gcc 编译的 C 代码调用 Go 函数 p.GoF 成为可能，cgo 编写了以 GoF 命名的 gcc 编译的函数 （不是 p.GoF，因为 gcc 没有包的概念）。然后 gcc 编译的 C 函数 f 调用 GoF。 GoF 调用了 crosscall2(_cgoexp_GoF, frame, framesize)，而 Crosscall2（gcc 编译的汇编文件）为一个具有两个参数的从 gcc 函数调用 ABI 到 6c 函数调用 API 的适配器。 gcc 通过调用它来调用 6c 函数。这种情况下，它会调用 _cgoexp_GoF(frame, framesize)， 仍然会在 m.g0 栈上运行，且不受 $GOMAXPROCS 的限制。因此该代码不能直接调用任意的 Go 代码， 并且必须非常小心的分配内存以及小心的使用 m.g0 栈。
    _cgoexp_GoF 调用了 runtime.cgocallback(p.GoF, frame, framesize, ctxt)。 （使用 _cgoexp_GoF 而不是编写 crosscall3 直接进行此调用的原因是 _cgoexp_GoF 是用 6c 而不是 gcc 编译的，可以引用像 runs.cgocallback 和 p.GoF 这样的带点的名称。） runtime.cgocallback 从 m.g0 的堆切换到原始 g（m.curg）的栈， 并在在栈上调用 runtime.cgocallbackg(p.GoF，frame，framesize)。 作为栈切换的一部分，runtime.cgocallback 将当前 SP 保存为 m.g0.sched.sp， 因此在执行回调期间任何使用 m.g0 的栈都将在现有栈帧之下完成。 在覆盖 m.g0.sched.sp 之前，它会在 m.g0 栈上将旧值压栈，以便以后可以恢复。
    runtime.cgocallbackg 现在在一个真正的 goroutine 栈上运行（不是 m.g0 栈）。 首先它调用 runtime.exitsyscall，它将阻塞到不与 $GOMAXPROCS 限制冲突的情况下运行此 goroutine。 一旦 exitsyscall 返回，就可以安全地执行调用内存分配器或调用 Go 的 p.GoF 回调函数等操作。
    runtime.cgocallbackg 首先推迟一个函数来 unwind m.g0.sched.sp，这样如果 p.GoF 发生 panic m.g0.sched.sp 将恢复到其旧值：m.g0 栈和 m.curg 栈将在 unwind 步骤中展开。 接下来它调用 p.GoF。最后它弹出但不执行 defer 函数，而是调用 runtime.entersyscall， 并返回到 runtime.cgocallback。 在重新获得控制权后，runtime.cgocallback 切换回 m.g0 栈（指针仍然为 m.g0.sched.sp）， 从栈中恢复原来的 m.g0.sched.sp 的值，并返回到 _cgoexp_GoF。 _cgoexp_GoF 直接返回 crosscall2，从而为 gcc 恢复调用方寄存器，并返回到 GoF，从而返回到 f 中。
    f --> GoF --> crosscall2 --> _cgoexp_GoF --> runtime.cgocallbackg --> runtime.cgocallback --> runtime.exitsyscall --> p.GoF
                                                                                                                     |
                                                                                                                     |
f <-- GoF <-- crosscall2 <-- _cgoexp_GoF <-- runtime.cgocallback <-- runtime.entersyscall <-----------------------------+

    实际代码

    // 从 C 调用 Go
    //go:nosplit
    func cgocallbackg(ctxt uintptr) {
    gp := getg()
    (…)

// 从 C 发起的调用运行在 gp.m 的 g0 栈上，因此我们必须确认我们停留在这个 M 上
// 在调用 exitsyscall 之前，必须调用这个操作，否则它会被释放且将我们移动到其他的 M 上
// 当前调用结束前，会调用 unlockOSThread
lockOSThread()

// 保存当前系统调用的参数，因此 m.syscall 可以在进行系统调用时候进而回调使用
syscall := gp.m.syscall

// entersyscall 保存了调用方 SP 并允许 GC 能够跟踪 Go 栈。然而因为我们会返回到
// 前一个栈帧并需要与 cgocall 的 entersyscall() 匹配，我们必须保存 syscall*
// 并让 reentersyscall 恢复它们
savedsp := unsafe.Pointer(gp.syscallsp)
savedpc := gp.syscallpc
exitsyscall() // 离开 cgo 调用
gp.m.incgo = false

cgocallbackg1(ctxt)

// 这时，unlockOSThread 已经被调用，下面的代码不能修改到其他的 m 上。
// incgo 检查位于 schedule 函数中，这是强制的

gp.m.incgo = true
// 返回到 cgo 调用going back to cgo call
reentersyscall(savedpc, uintptr(savedsp))

gp.m.syscall = syscall
}

func cgocallbackg1(ctxt uintptr) {
gp := getg()
if gp.m.needextram || atomic.Load(&extraMWaiters) > 0 {
gp.m.needextram = false
systemstack(newextram)
}

if ctxt != 0 {
s := append(gp.cgoCtxt, ctxt)

 // 现在我们需要设置 gp.cgoCtxt = s，但我们可以得到操纵切片时的 SIGPROF 信号，和<br />     // SIGPROF 处理程序可以获取 gp.cgoCtxt<br />     // 追踪堆栈。我们需要确保 handler 总是看到一个有效的切片，所以设置<br />     // 按顺序排列的值，以便始终如此。<br />     p := (*slice)(unsafe.Pointer(&gp.cgoCtxt))<br />     atomicstorep(unsafe.Pointer(&p.array), unsafe.Pointer(&s[0]))<br />     p.cap = cap(s)<br />     p.len = len(s)

 defer func(gp *g) {<br />   // 安全地减少切片的长度。<br />   p := (*slice)(unsafe.Pointer(&gp.cgoCtxt))<br />   p.len--<br />     }(gp)<br /> }

if gp.m.ncgo == 0 {
// 对 Go 的 C 调用来自一个当前没有运行任何 Go 的线程。
// 在 -buildmode=c-archive 或 c-shared 的情况下，
// 此调用可能在包初始化完成之前进入，等待完成。
<-main_init_done
}

// 增加 defer 栈的入口来防止 panic
restore := true
defer unwindm(&restore)

(…)

type args struct {
fn funcval
arg unsafe.Pointer
argsize uintptr
}
var cb args

// Location of callback arguments depends on stack frame layout
// and size of stack frame of cgocallback_gofunc.
sp := gp.m.g0.sched.sp
switch GOARCH {
(…)
case “amd64”:
// On amd64, stack frame is two words, plus caller PC.
if framepointer_enabled {
// In this case, there’s also saved BP.
cb = (args)(unsafe.Pointer(sp + 4sys.PtrSize))
break
}
cb = (args)(unsafe.Pointer(sp + 3sys.PtrSize))
(…)
}

// 调用的回调函数
// 注意(rsc): 传递 nil 为 argtype 意味着复制
// 结果回到 cb.arg 没有任何相应的写入障碍。
// 对于 cgo，cb.arg 指向 C 堆栈帧，因此不会
// 保留 GC 可以找到的任何指针 - 写屏障将是一个空操作。
reflectcall(nil, unsafe.Pointer(cb.fn), cb.arg, uint32(cb.argsize), 0)

(….)

// 不对 m->g0->sched.sp 进行 unwind
// cgocallback 会进行处理
restore = false
}

小结

TODO:

进一步阅读的参考文献

  1. Command cgo
  2. LINUX SYSTEM CALL TABLE FOR X86 64