At the bottom of a Go func with defer, the assembly looks like this:
0x000000000047e1a0 < 256>: callq *%rsi
0x000000000047e1a2 < 258>: movb $0x0,0x7(%rsp)
0x000000000047e1a7 < 263>: mov 0x748(%rsp),%rdx
0x000000000047e1af < 271>: mov (%rdx),%rbx
0x000000000047e1b2 < 274>: callq *%rbx
0x000000000047e1b4 < 276>: mov 0x750(%rsp),%rbp
0x000000000047e1bc < 284>: add $0x758,%rsp
0x000000000047e1c3 < 291>: retq
0x000000000047e1c4 < 292>: callq 0x42ea40 <runtime.deferreturn>
0x000000000047e1c9 < 297>: mov 0x750(%rsp),%rbp
0x000000000047e1d1 < 305>: add $0x758,%rsp
0x000000000047e1d8 < 312>: retq
0x000000000047e1d9 < 313>: callq 0x458900 <runtime.morestack>
As we can see, there is a retq
before call runtime.deferreturn
. So, it seems that the deferreturn
will never be called. Do I understand this right?
CodePudding user response:
As we can see, there is a retq before call runtime.deferreturn. So, it seems that the deferreturn will never be called. Do I understand this right?
No. The code may be used by the Go runtime, for example, while panicking.