Go_dlv_autogenerate_代码定位

这个问题是在通过dlv trace rt0_go时候出现的，情况如下

打断点runtime.args，出现如下内容

(dlv) b runtime.args
Breakpoint 1 set at 0x45e160 for runtime.args() <autogenerated>:1

执行continue，出现如下内容

(dlv) c
> runtime.args() <autogenerated>:1 (hits total:1) (PC: 0x45e160)
Warning: debugging optimized function

正常打断点如下：

(dlv) b rt0_go
Breakpoint 1 set at 0x459980 for runtime.rt0_go() /usr/local/go/src/runtime/asm_amd64.s:83
(dlv) c
> runtime.rt0_go() /usr/local/go/src/runtime/asm_amd64.s:83 (hits total:1) (PC: 0x459980)
Warning: debugging optimized function
    78: DATA _rt0_amd64_lib_argv<>(SB)/8, $0
    79: GLOBL _rt0_amd64_lib_argv<>(SB),NOPTR, $8
    80:
    81: TEXT runtime·rt0_go(SB),NOSPLIT|TOPFRAME,$0
    82:         // copy arguments forward on an even stack
=>  83:         MOVQ    DI, AX          // argc
    84:         MOVQ    SI, BX          // argv
    85:         SUBQ    $(4*8+7), SP            // 2args 2auto
    86:         ANDQ    $~15, SP
    87:         MOVQ    AX, 16(SP)
    88:         MOVQ    BX, 24(SP)

会到具体的调用的地方，但是runtime.args不会，但这不是runtime.args的问题，查了下delve的issue，看到这篇issue：Step into autogenerated tail calls · Issue #1908 · go-delve/delve (github.com)

觉得问题看起来是go编译器会对某些代码生成一些warpper，看着是调到runtime.args，但是实际disassemble之后，不是我们打断点的地方，所以需要用比较不同的方式查看到真正调用到的函数，步骤如下(重头来的)：

1. b runtime.args
2. c

前两步和之前一样

3. disassemble

   

   可以看到其实调runtime.args的地址是0x45e184，我们需要做的就是打断点到0x45e184

4. b *0x45e184

5. c

6. disassemble

   

7. si

   

   就可以找到真正调用方法的地方

---

真正这个go编译器为什么会这么做，不太清楚，我的目的就是找到autogenerate后面真正调用的地方，有能解释明白autogenerate的朋友可以交流下