pkg debug/gosym 应用

数据类型及关系

标准库提供了package debug/gosym 来读取go工具链为go语言生成的一些特有的section数据，如.gosymtab、.gopclntab。其为go语言运行时提供了一种高效快速的计算调用栈的方法，这在go语言出现panic希望打印堆栈信息的时候非常有帮助。

package debug/gosym中的相关重要数据结构，如下图所示：

gopkg debug/gosym

关于go定制的.gosymtab、.gopclntab相关的符号信息设计，可以参考 Go 1.2 Runtime Symbol Information，整体来看，比较重要的就是“Table”这个数据结构，注意到它有几个非常实用的导出方法，我们可以用来在指令地址与源文件位置之前进行快速的转换，借此可以实现一个调用栈追踪的能力。.gosymtab、.gopclntab的主要目的也是在此。

go定制的sections

ELF文件中符号表信息一般会存储在.symtab section中，go程序有点特殊在go1.2及之前的版本有一个特殊的.gosymtab，其中存储了接近plan9风格的符号表结构信息，但是在go1.3之后，.gosymtab不再包含任何符号信息。

另外，ELF文件存储调试用的行号表、调用栈信息，如果是DWARF调试信息格式的话，一版是存储在.[z]debug_line、.[z]debug_frame中。go程序比较特殊，为了使程序在运行时可以可靠地跟踪调用栈，go编译工具链生成了一个名为.gopclntab的section，其中保存了go程序的行号表信息。

那么，go为什么不使用.[z]debug_line、.[z]debug_frame sections呢？为什么要独立添加一个.gosymtab、.gopclntab呢？这几个sections有什么区别呢？

  • 我们确定的是.[z]debug_前缀开头的sections中包含的是调试信息，是给调试器等使用的，.gosymtab、.gopclntab则是给go运行时使用的。

  • go程序执行时，其运行时部分会加载.gosymtab、.gopclntab的数据到进程内存中，用来执行栈跟踪（stack tracebacks），比如runtime.Callers。但是.symtab、.[z]debug_* sections并没有被加载到内存中，它是由外部调试器来读取并加载的，如gdb、delve。

      $ readelf -l <prog>

  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    PHDR           ...
    NOTE           ...
    LOAD           ...// 02 .note.go.builid
    LOAD           ...// 03 .rodata ... .gosymtab .gopclntab
    LOAD           ...// 04 .go.buildinfo ...
    GNU_STACK      ...
    LOOS+5041580   ...

   Section to Segment mapping:
    Segment Sections...
     00     
     01     .note.go.buildid 
     02     .text .note.go.buildid 
     03     .rodata .typelink .itablink .gosymtab .gopclntab 
     04     .go.buildinfo .noptrdata .data .bss .noptrbss 
     05     
     06

    对一个构建好的go程序执行命令readelf -l <prog>我们可以看到段索引02、03、04位LOAD类型表示是要加载到内存中的，这个段对应的sections也显示包含.gosymtab、.gopclntab但是不包含.[z]debug_*相关的sections。

    这既符合常见编程语言、工具链的惯例，也是为了更高效地在指令地址、源码行之间做转换，后面会介绍go是如何做转换的。

可能会有疑问，为什么go程序不直接利用.symtab、.[z]debug_* sections呢，这几个sections中的数据结合起来也足以实现栈跟踪？

目前我了解到的是，DWARF数据的解析、使用应该会更复杂一点，go早期核心开发者很多有Plan9的工作经验，在研发Plan9时就已经有了类似pclntab的尝试，从Plan9的man手册中可以查看到相关的信息。

Plan9's man a.out

NAME
    a.out - object file format

 SYNOPSIS
    #include <a.out.h>

DESCRIPTION
    An executable Plan 9 binary file has up to six sections: a
    header, the program text, the data, a symbol table, a PC/SP
    offset table (MC68020 only), and finally a PC/line number
    table.  The header, given by a structure in <a.out.h>, con-
    tains 4-byte integers in big-endian order:

   ....

   A similar table, occupying pcsz-bytes, is the next section
   in an executable; it is present for all architectures.  The
   same algorithm may be run using this table to recover the
   absolute source line number from a given program location.
   The absolute line number (starting from zero) counts the
   newlines in the C-preprocessed source seen by the compiler.
   Three symbol types in the main symbol table facilitate con-
   version of the absolute number to source file and line num-
   ber:

go程序的很多核心开发者本身就是Plan9的开发者，go中借鉴Plan9的经验也就不足为奇了，早期pclntab的存储结构与plan9下程序的pclntab很接近，但是现在已经差别很大了，可以参考go1.2 pclntab的设计proposal：Go 1.2 Runtime Symbol Information。

注：另外提一下，cgo程序中，似乎是没有.gosymtab、.gopclntab的。

通过package debug/gosym可以构建出pcln table，通过其方法PcToLine、LineToPc等，可以帮助我们快速查询指令地址与源文件中位置的关系，也可以通过它来进一步分析调用栈，如程序panic时我们希望打印调用栈来定位出错的位置。

我理解，对调用栈信息的支持才是.gosymtab、.gopclntab所主要解决的问题，go1.3之后调用栈数据应该是完全由.gopclntab支持了，所以.gosymtab也就为空了。和调试器需要的.[z]debug_line、.[z]debug_frame等在设计目的上有着很大区别，其中.[z]debug_frame不仅可以追踪调用栈信息，也可以追踪每一个栈帧中的寄存器数据的变化，其数据编码、解析、运算逻辑也更加复杂。

那.gosymtab、.gopclntab能否用于调试器呢？也不能说完全没用，只是这里面的数据相对DWARF调试信息来说，缺失了一些调试需要的信息，我们还是需要用到DWARF才能完整解决调试场景中的问题。

现在我们应该清楚package debug/gosym以及对应.gosymtab、.gopclntab sections的用途了，也应该清楚与.symtab以及调试相关的.[z]debug_*这些sections的区别了。

常用操作及示例

这是我们的一个测试程序 testdata/loop2.go，我们先展示下其源文件信息，接下来执行go build -gcflags="all=-N -l" -o loop2 loop2.go将其编译成可执行程序loop2，后面我们读取loop2并继续做实验。

PC与源文件互转

testdata/loop2.go：

     1  package main
     2  
     3  import (
     4      "fmt"
     5      "os"
     6      "time"
     7  )
     8  
     9  func init() {
    10      go func() {
    11          for {
    12              fmt.Println("main.func1 pid:", os.Getpid())
    13              time.Sleep(time.Second)
    14          }
    15      }()
    16  }
    17  func main() {
    18      for {
    19          fmt.Println("main.main pid:", os.Getpid())
    20          time.Sleep(time.Second * 3)
    21      }
    22  }

下面我们通过debug/gosym来写个测试程序，目标是实现虚拟内存地址pc和源文件位置、函数之间的转换。

main.go：

package main

import (
    "debug/elf"
    "debug/gosym"
)

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "usage: go run main.go <prog>")
        os.Exit(1)
    }
    prog := os.Args[1]

    // open elf
    file, err := elf.Open(prog)
    if err != nil {
        panic(err)
    }

    gosymtab, _ := file.Section(".gosymtab").Data()
    gopclntab, _ := file.Section(".gopclntab").Data()

    pclntab := gosym.NewLineTable(gopclntab, file.Section(".text").Addr)
    table, _ := gosym.NewTable(gosymtab, pclntab)

    // table.LineToPC(line, num), here `line` must be absolute path
    pc, fn, err := table.LineToPC("/root/debugger101/testdata/loop2.go", 3)
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Printf("pc => %#x\tfn => %s\n", pc, fn.Name)
    }

    pc, fn, _ = table.LineToPC("/root/debugger101/testdata/loop2.go", 9)
    fmt.Printf("pc => %#x\tfn => %s\n", pc, fn.Name)

    pc, fn, _ = table.LineToPC("/root/debugger101/testdata/loop2.go", 11)
    fmt.Printf("pc => %#x\tfn => %s\n", pc, fn.Name)

    pc, fn, _ = table.LineToPC("/root/debugger101/testdata/loop2.go", 17)
    fmt.Printf("pc => %#x\tfn => %s\n", pc, fn.Name)

    // here 0x4b86cf is hardcoded, it's the address of loop2.go:9
    f, l, fn := table.PCToLine(0x4b86cf)
    fmt.Printf("pc => %#x\tfn => %s\tpos => %s:%d\n", 0x4b86cf, fn.Name, f, l)
}

运行测试go run main.go ../testdata/loop2，注意以上程序中指定源文件时使用了绝对路径，我们将得到如下输出：

$ go run main.go ../testdata/loop2
no code at /root/debugger101/testdata/loop2.go:3
pc => 0x4b86cf  fn => main.init.0.func1
pc => 0x4b8791  fn => main.init.0.func1
pc => 0x4b85b1  fn => main.main
pc => 0x4b86cf  fn => main.init.0.func1 pos => /root/debugger101/testdata/loop2.go:9

在上述测试程序中，我们一开始指定了一个源文件位置loop2.go:3的位置，查看源码可知，这个位置处是一些import声明，没有函数，所以这里找不到对应的指令，所以才会返回错误信息“no code at ....loop2.go:3”。剩余几行测试都指定了有效的源码位置，分别输出了几个源文件位置对应的指令地址。

然后我们从输出的结果中选择第一个测试case loop2.go:9的pc值0x4b86cf作为table.PCToLine(...)的参数来测试从pc转换为源文件位置，程序正确输出了源文件位置。

运行时栈跟踪

go程序除了通过error来传播错误，还有一种方式是通过panic来传播异常，由于panic传播路径可能会比较长，直到它被当前goroutine recover或者进程crash。

当出现panic时，如果我们主动recover了，也会希望通过打印调用栈来追踪问题的源头；如果没有recover导致进程crash了，那么运行时也会打印每个goroutine的调用栈信息。两种方式的目的都是为了帮助我们容易定位panic的源头位置。

下面是一个演示go程序panic时recover并打印调用栈信息的示例：

main.go

1  package main
2  
3  import (
4      "runtime/debug"
5  )
6  
7  func main() {
8      defer func() {
9          if e := recover(); e != nil {
10              debug.PrintStack()
11          }
12      }()
13      f1()
14  }
15  
16  func f1() {
17      f2()
18  }
19  
20  func f2() {
21      panic("let's panic")
22  }

运行go run main.go进行测试：

$ go run main.go

goroutine 1 [running]:
runtime/debug.Stack(0xc00001408b, 0x8, 0xc000096df0)
    /usr/local/go/src/runtime/debug/stack.go:24 +0x9f
runtime/debug.PrintStack()
    /usr/local/go/src/runtime/debug/stack.go:16 +0x25
main.main.func1()
    /Users/zhangjie/main.go:10 +0x45
panic(0x1084480, 0x10aff40)
    /usr/local/go/src/runtime/panic.go:969 +0x175
main.f2(...)
    /Users/zhangjie/main.go:21
main.f1(...)
    /Users/zhangjie/main.go:17
main.main()
    /Users/zhangjie/main.go:13 +0x5d

上述调用栈信息如何看呢：

  • 首先从上往下看，runtime/debug.Stack->runtime/debug.PrintStack->main.main.func1，这里是panic被recover的位置；
  • 继续往下看，可以看到panic在何处生成的，panic->main.f2，注意到这个函数第21行调用了panic方法，找到panic发生的位置了；
  • 调用栈剩下的就没有必要看了；

前面我们不止一次提到go运行时调用栈信息是基于.gopclntab构建出来的，but how？

栈跟踪如何实现

实现栈跟踪的常见方法

栈跟踪（stack unwinding）如何实现呢，我们先来说下一般性的思路：

  • 首先获取当前程序的pc信息，pc确定了就可以确定当前函数f对应的栈帧；
  • 再获取当前程序的bp信息（go里面称为fp），进而可以拿到函数返回地址；
  • 返回地址往往就是在caller对应的函数的栈帧中了，将该返回地址作为新的pc；
  • 重复前面几步，直到栈跟踪深度达到要求为止；
go runtime利用.gopclntab实现栈跟踪

要理解这点首先应该理解.gopclntab的设计，这部分内容可以参考Go 1.2 Runtime Symbol Information，然后我们可以看下实现，即gosym.Table及相关类型的结构。

在本文开头我们已经展示了package debug/gosym的设计，从中我们可以看到Table表结构包含了很多Syms、Funcs、Files、Objs，进一步结合其暴露的Methods不难看出，我们可以轻松地在pc、file、lineno、func之间进行转换。

考虑下调用栈是什么，调用栈是一系列方法调用的caller-callee关系，这个Table里面可没有，它只是用来辅助查询的。

  • 如果要获得调用栈，首先你要能拿到goroutine当前的pc值，这个go runtime肯定可以拿到，有了pc我们就可以通过gosym.Table找到当前函数名；
  • 然后我们需要知道当前函数调用的返回地址，那就需要通过go runtime获得bp（go里面称之为fp），通过它找到存放返回地址的位置，拿到返回地址；
  • 返回地址绝大多数情况下都是返回到caller对应的函数调用中（除非尾递归优化不返回，但是go编译器不支持尾递归优化，所以忽略），将这个返回地址作为pc，去gosym.Table中找对应的函数定义，这样就确定了一个caller；
  • 重复上述过程即可，直到符合栈跟踪的深度要求。

go标准库runtime/debug.PrintStack()就是这么实现的，只是它考虑的更周全，比如打印所有goroutine调用栈需要STW，调用栈信息过大可能超出goroutine栈上限，所以会先切到systemstack再生成调用栈信息，会考虑对gc的影响，等等。

调试器利用.gopclntab+FDE实现栈跟踪

根据前面对gosym.Table的分析，我们很容易明白，如果只是单纯利用.gopclntab来实现stack unwinding，那是不可能的，至少还要知道pc、bp信息。而且调试器里面也很难像go runtime那样灵活自如地对goroutine进行控制，如获取goroutine的各种上下文信息。

那调试器应该如何做呢？

研究delve源码发现，在go-delve/delve@913153e7及之前的版本中是借助gosym.Table结合DWARF FDE实现的：

  • dlv首先利用DWARF .debug_frame section来构建FDE列表；

  • dlv获得tracee的pc值，然后遍历FDE列表，找到FDE地址范围覆盖pc的FDE，这个FDE就是对应的函数栈帧了；

  • 然后再找caller，此时dlv再获取bp值，再计算出返回地址位置，再读取返回地址，然后再去遍历FDE列表找地址范围覆盖这个返回地址的FDE，这个FDE对应的就是caller；
  • 重复以上过程即可，直到符合栈跟踪深度要求；

找caller-callee关系，dlv就是按上述过程处理的，至于callee当前pc以及caller调用当前函数处的pc，这些虚拟内存地址对应的函数名、源文件位置信息，还是通过gosym.Table来转换实现的。

其实这里go-delve/delve的实现走了一点“捷径”，本来它可以通过.[z]debug_line来实现pc和file:lineno的转换，也可以通过.[z]debug_frame来确定调用栈。

这里需要明确的是，.gopclntab只记录了纯go程序的pc、源文件位置映射信息，对于cgo程序的部分是不包含的，因为c编译器都不理解有这些东西的，因此有一定的局限性。但是生成.[z]debug_line、.[z]debug_frame信息，常见编译器都是支持的，是可以更好地解决这里的局限性问题的。

go-delve/delve@6d405179，项目核心开发aarzilli解决了这个问题，并在提交记录里特别强调了用.[z]debug_line来代替.gosymtab、.gopclntab这个问题：

commit 6d40517944d40113469b385784f47efa4a25080d
Author: aarzilli <alessandro.arzilli@gmail.com>
Date:   Fri Sep 1 15:30:45 2017 +0200

    proc: replace all uses of gosymtab/gopclntab with uses of debug_line

    gosymtab and gopclntab only contain informations about go code, linked
    C code isn't there, we should use debug_line instead to also cover C.

    Updates #935

ok，这里大家应该明白实现原理了，我们将在下一章调试器开发过程中加以实践。

本节小结

本节介绍了标准库debug/gosym包的设计，并演示了如何在指令地址和源代码位置之间进行转换。也介绍了标准库debug.PrintStack()如何基于.gosymtab、.gopclntab实现运行时调用栈跟踪。也介绍了大名鼎鼎的delve调试器早期如何利用.gosymtab、.gopclntab + DWARF FDE实现栈跟踪，以及后续为了兼容cgo又如何迁移到DWARF .[z]debug_line、.[z]debug_frame来更全面地支持调试。

大家对于这部分内容已经有些了解，接下来我们将开始接触调试信息标准DWARF。

参考内容

  1. How to Fool Analysis Tools, https://tuanlinh.gitbook.io/ctf/golang-function-name-obfuscation-how-to-fool-analysis-tools

  2. Go 1.2 Runtime Symbol Information, Russ Cox, https://docs.google.com/document/d/1lyPIbmsYbXnpNj57a261hgOYVpNRcgydurVQIyZOz_o/pub

  3. Some notes on the structure of Go Binaries, https://utcc.utoronto.ca/~cks/space/blog/programming/GoBinaryStructureNotes

  4. Buiding a better Go Linker, Austin Clements, https://docs.google.com/document/d/1D13QhciikbdLtaI67U6Ble5d_1nsI4befEd6_k1z91U/view

  1. Time for Some Function Recovery, https://www.mdeditor.tw/pl/2DRS/zh-hk

results matching ""

    No results matching ""