现在越来越多的java、php或者python程序员转向了Golang。其中一个比较重要的原因是，它和C/C++一样，可以编译成机器码运行，这保证了执行的效率。在上述解释型语言中，它们都支持了“反射”机制，让程序员可以很方便的构建一些动态逻辑。这是C/C++相对薄弱的环节，而Golang却有良好的支持。本系列，我们将通过反汇编Golang的编译结果，探究其反射实现的机制。（转载请指明出于breaksoftware的csdn博客）

为了防止编译器做优化，例子中的源码都通过下面的指令编译

go build -gcflags "-N -l" [xxxxxx].go

类型名称

基本类型

package mainimport ("fmt""reflect"
)func main() {t := reflect.TypeOf(1)s := t.Name()fmt.Println(s)
}

这段代码最终将打印出1的类型——int。

main函数的入口地址是main.main。我们使用gdb在这个位置下断点，然后反汇编。略去一部分函数准备工作，我们看到

   0x0000000000487c6f <+31>:    mov    %rbp,0xa0(%rsp)0x0000000000487c77 <+39>:    lea    0xa0(%rsp),%rbp0x0000000000487c7f <+47>:    lea    0xfb5a(%rip),%rax        # 0x4977e00x0000000000487c86 <+54>:    mov    %rax,(%rsp)0x0000000000487c8a <+58>:    lea    0x40097(%rip),%rax        # 0x4c7d28 <main.statictmp_0>0x0000000000487c91 <+65>:    mov    %rax,0x8(%rsp)0x0000000000487c96 <+70>:    callq  0x46f210 <reflect.TypeOf>

第3~4行，这段代码将地址0x4977e0压栈。之后在5~6行，又将0x4c7d28压栈。64位系统下，程序的压栈不像32位系统使用push指令，而是使用mov指令间接操作rsp寄存器指向的栈空间。

第7行，调用了reflect.TypeOf方法，在Golang的源码中，该方法的相关定义位于\src\reflect\type.go中

// TypeOf returns the reflection Type that represents the dynamic type of i.
// If i is a nil interface value, TypeOf returns nil.
func TypeOf(i interface{}) Type {eface := *(*emptyInterface)(unsafe.Pointer(&i))return toType(eface.typ)
}// toType converts from a *rtype to a Type that can be returned
// to the client of package reflect. In gc, the only concern is that
// a nil *rtype must be replaced by a nil Type, but in gccgo this
// function takes care of ensuring that multiple *rtype for the same
// type are coalesced into a single Type.
func toType(t *rtype) Type {if t == nil {return nil}return t
}

reflect.emptyInterface是一个保存数据类型信息和裸指针的结构体，它位于\src\reflect\value.go

// emptyInterface is the header for an interface{} value.
type emptyInterface struct {typ  *rtypeword unsafe.Pointer
}

之前压栈的两个地址0x4977e0和0x4c7d28分别对应于type和word。

(gdb) x/16xb $rsp
0xc42003fed0:   0xe0    0x77    0x49    0x00    0x00    0x00    0x00    0x00
0xc42003fed8:   0x28    0x7d    0x4c    0x00    0x00    0x00    0x00    0x00

这样在内存上便构成了一个emptyInterface结构。下面我们查看它们的内存，0x4c7d28保存的值0x01即是我们传入reflect.TypeOf的值。

0x4977e0:       0x08    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x4c7d28 <main.statictmp_0>:    0x01    0x00    0x00    0x00    0x00    0x00    0x00    0x00

reflect.rtype定义位于src\reflect\type.go

// rtype is the common implementation of most values.
// It is embedded in other struct types.
//
// rtype must be kept in sync with ../runtime/type.go:/^type._type.
type rtype struct {size       uintptr……str        nameOff  // string formptrToThis  typeOff  // type for pointer to this type, may be zero
}

在reflect.TypeOf方法中，我们看到reflect.toType隐式的将reflect.rtype转换成了reflect.Type类型，而reflect.Type类型和它完全不一样

type Type interface {Align() intFieldAlign() intMethod(int) Method……
}

从Golang的源码的角度去解析似乎进入了死胡同，我们继续转向汇编层面，查看reflect.TypeOf的实现

   0x000000000046f210 <+0>:     mov    0x8(%rsp),%rax0x000000000046f215 <+5>:     test   %rax,%rax0x000000000046f218 <+8>:     je     0x46f22c <reflect.TypeOf+28>0x000000000046f21a <+10>:    lea    0xaddbf(%rip),%rcx        # 0x51cfe0 <go.itab.*reflect.rtype,reflect.Type>0x000000000046f221 <+17>:    mov    %rcx,0x18(%rsp)0x000000000046f226 <+22>:    mov    %rax,0x20(%rsp)0x000000000046f22b <+27>:    retq   0x000000000046f22c <+28>:    xor    %eax,%eax0x000000000046f22e <+30>:    mov    %rax,%rcx0x000000000046f231 <+33>:    jmp    0x46f221 <reflect.TypeOf+17>

之前介绍过，在调用reflect.TypeOf前，已经在栈上构建了一个emptyInterface结构体。由于此函数只关注类型，而不关注值，所以此时只是使用了typ字段——rsp+0x08地址的值。

比较有意思的是这个过程获取了一个内存地址0x51cfe0，目前我们尚不知它是干什么的。之后我们会再次关注它。

   0x0000000000487c9b <+75>:    mov    0x10(%rsp),%rax0x0000000000487ca0 <+80>:    mov    0x18(%rsp),%rcx0x0000000000487ca5 <+85>:    mov    %rax,0x38(%rsp)0x0000000000487caa <+90>:    mov    %rcx,0x40(%rsp)0x0000000000487caf <+95>:    mov    0xc0(%rax),%rax0x0000000000487cb6 <+102>:   mov    %rcx,(%rsp)0x0000000000487cba <+106>:   callq  *%rax

从reflect.TypeOf调用中返回后，rax寄存器保存的是0x51cfe0，然后在第5行计算了该地址偏移0xC0的地址中保存的值。最后在第7行调用了该地址所指向的函数。

(gdb) x/64bx 0x51cfe0+0xc0 
0x51d0a0 <go.itab.*reflect.rtype,reflect.Type+192>:     0x80    0xcc    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0a8 <go.itab.*reflect.rtype,reflect.Type+200>:     0xf0    0xd6    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0b0 <go.itab.*reflect.rtype,reflect.Type+208>:     0x60    0xd7    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0b8 <go.itab.*reflect.rtype,reflect.Type+216>:     0xe0    0xbe    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0c0 <go.itab.*reflect.rtype,reflect.Type+224>:     0xd0    0xd7    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0c8 <go.itab.*reflect.rtype,reflect.Type+232>:     0x80    0xd8    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0d0 <go.itab.*reflect.rtype,reflect.Type+240>:     0x90    0xcb    0x46    0x00    0x00    0x00    0x00    0x00
0x51d0d8 <go.itab.*reflect.rtype,reflect.Type+248>:     0x60    0xb9    0x46    0x00    0x00    0x00    0x00    0x00

使用反汇编指令看下0x46cc80处的函数，可以看到它是reflect.(*rtype).Name()

(gdb) disassemble 0x46cc80
Dump of assembler code for function reflect.(*rtype).Name:

我们再看0x51d0a0附近的内存中的值，发现其很有规律。其实它们都是reflect.(*rtype)下的函数地址。

(gdb) disassemble 0x46b960
Dump of assembler code for function reflect.(*rtype).Size:(gdb) disassemble 0x46cb90
Dump of assembler code for function reflect.(*rtype).PkgPath:

这些方法也是reflect.Type接口暴露的方法。当我们调用Type暴露的方法的时候，实际底层调用的rtype对应的同名方法。

type Type interface {Align() intFieldAlign() int……Name() stringPkgPath() stringSize() uintptr……
}

从reflect.TypeOf调用返回后，就调用reflect.(*rtype).Name()。它的相关实现是

func (t *rtype) Name() string {if t.tflag&tflagNamed == 0 {return ""}s := t.String()……return s[i+1:]
}func (t *rtype) String() string {s := t.nameOff(t.str).name()if t.tflag&tflagExtraStar != 0 {return s[1:]}return s
}type name struct {bytes *byte
}func (t *rtype) nameOff(off nameOff) name {return name{(*byte)(resolveNameOff(unsafe.Pointer(t), int32(off)))}
}

这段代码表示，变量的类型值和rtype的地址和rtype.str字段有关。而这个rtype就是reflect.TypeOf调用前构建的emptyInterface的rtype。我们使用gdb查看该结构体

$4 = {size = 0x8, ptrdata = 0x0, hash = 0xf75371fa, tflag = 0x7, align = 0x8, fieldAlign = 0x8, kind = 0x82, alg = 0x529a70, gcdata = 0x4c6cd8, str = 0x3a3, ptrToThis = 0xac60
}

最后我们就要看相对复杂的resolveNameOff实现。

func resolveNameOff(ptrInModule unsafe.Pointer, off nameOff) name {if off == 0 {return name{}}base := uintptr(ptrInModule)for md := &firstmoduledata; md != nil; md = md.next {if base >= md.types && base < md.etypes {res := md.types + uintptr(off)if res > md.etypes {println("runtime: nameOff", hex(off), "out of range", hex(md.types), "-", hex(md.etypes))throw("runtime: name offset out of range")}return name{(*byte)(unsafe.Pointer(res))}}}// No module found. see if it is a run time name.reflectOffsLock()res, found := reflectOffs.m[int32(off)]reflectOffsUnlock()if !found {println("runtime: nameOff", hex(off), "base", hex(base), "not in ranges:")for next := &firstmoduledata; next != nil; next = next.next {println("\ttypes", hex(next.types), "etypes", hex(next.etypes))}throw("runtime: name offset base pointer out of range")}return name{(*byte)(res)}
}

我们先忽略17行之后的代码。从6~15行，程序会遍历模块信息，并检测rtype地址是否在该区间之内（base >= md.types && base < md.etypes）。如果在此区间，则返回相对于该区间起始地址的off偏移地址。

所以，rtype.str字段的偏移不是相对于rtype的起始地址。而是相对于rtype起始地址所在的区间的保存type信息区块（[md.types, md.etypes)）起始地址。

和rtype信息一样，firstmoduledata的信息也是全局初始化的。我们使用IDA协助查看它位置。

可以看到这些数据都存储在elf的.noptrdata节中，该节中数据是Golang构建程序时保存全局数据的地方。所以这种“反射”是编译器在编译的过程中，暗中帮我们构建了和变量等有关的信息。

我们再看下模块起始地址0x488000偏移rtype.str=0x3a3的地址空间。

这样我们就看到int字段的来源了。

自定义结构类型

package mainimport ("fmt""reflect"
)type t20190107 struct {v string
}func main() {i2 := t20190107{"s20190107"}t2 := reflect.TypeOf(i2)s2 := t2.Name()fmt.Println(s2)
}

这段代码故意构建一个名字很特殊的结构体，我们看下反汇编的结果。

   0x0000000000487c6f <+31>:    mov    %rbp,0xc0(%rsp)0x0000000000487c77 <+39>:    lea    0xc0(%rsp),%rbp0x0000000000487c7f <+47>:    movq   $0x0,0x58(%rsp)0x0000000000487c88 <+56>:    movq   $0x0,0x60(%rsp)0x0000000000487c91 <+65>:    lea    0x2f868(%rip),%rax        # 0x4b75000x0000000000487c98 <+72>:    mov    %rax,0x58(%rsp)0x0000000000487c9d <+77>:    movq   $0x9,0x60(%rsp)0x0000000000487ca6 <+86>:    mov    %rax,0x98(%rsp)0x0000000000487cae <+94>:    movq   $0x9,0xa0(%rsp)0x0000000000487cba <+106>:   lea    0x196ff(%rip),%rax        # 0x4a13c00x0000000000487cc1 <+113>:   mov    %rax,(%rsp)0x0000000000487cc5 <+117>:   lea    0x98(%rsp),%rax0x0000000000487ccd <+125>:   mov    %rax,0x8(%rsp)0x0000000000487cd2 <+130>:   callq  0x40c7e0 <runtime.convT2E>

第5行，我们获取了0x4b7500空间地址，我们看下其值，就是我们初始化结构体的字面量“s20190107"

第10行，我们又获取了0x4a13c0地址。依据之前的经验，该地址保存的是reflect.rtype类型数据。但是由于之后调用的runtime.convT2E，所以其类型是runtime._type。

func convT2E(t *_type, elem unsafe.Pointer) (e eface) {if raceenabled {raceReadObjectPC(t, elem, getcallerpc(unsafe.Pointer(&t)), funcPC(convT2E))}if msanenabled {msanread(elem, t.size)}x := mallocgc(t.size, t, true)// TODO: We allocate a zeroed object only to overwrite it with actual data.// Figure out how to avoid zeroing. Also below in convT2Eslice, convT2I, convT2Islice.typedmemmove(t, x, elem)e._type = te.data = xreturn
}

其实runtime._type和reflect.rtype的定义是一样的

type _type struct {size       uintptr……str       nameOffptrToThis typeOff
}type rtype struct {size       uintptr……	str        nameOff  // string formptrToThis  typeOff  // type for pointer to this type, may be zero
}

而reflect.emptyInterface和runtime.eface也一样

type eface struct {_type *_typedata  unsafe.Pointer
}type emptyInterface struct {typ  *rtypeword unsafe.Pointer
}

这让我们对基本类型的分析结果和经验在此处依然适用。

使用gdb把_type信息打印出来，可以发现这次类型名称的偏移量0x6184比较大。

$3 = {size = 0x10, ptrdata = 0x8, hash = 0xe1c71878, tflag = 0x7, align = 0x8, fieldalign = 0x8, kind = 0x19, alg = 0x529a90, gcdata = 0x4c6dc4, str = 0x6184, ptrToThis = 0xae80
}

runtime.convT2E第8行在垃圾回收器上构建了一段内存，并将裸指针指向的数据保存到该地址空间中。然后在第12~13行重新构建了eface结构体。

之后进入reflect.TypeOf逻辑，这和之前分析的流程一致。我们最后看下保存的类型数据的全局区域

总结

• 编译器在编译过程中，将变量对应的类型信息（runtime._type或reflect.rtype）保存在.rodata节中。
• 字面量直接使用reflect.TypeOf方法获取rtype类型函数地址列表
• 变量使用runtime.convT2*类型转换函数，使用垃圾回收器上分配的空间存储变量值，然后调用reflect.TypeOf方法
• 遍历保存在.noptrdata节中的模块信息，确认类型信息的存储地址位于的模块区域。然后以该区块中保存type信息的区块起始地址为基准，使用rtype.str字段表示的偏移量计算出名称在内存中的位置。