What is this template in the build code generated by the go compiler?

Question

I was debugging an irrelevant problem in the Linux kernel and saw that the etcd process that the supervisor was running repeatedly hit the crash exception page and getting SIGSEGV.

I became curious, and I used objdump to parse the program, and found that the amd64 instruction had an error:

89 04 25 00 00 00 00 mov %eax,0x0 

Then I looked at the disassembly of the welcome world program. I saw a very common picture in the code generated by the go compiler, which is located at the end of the function, immediately after ret , there is mov , and then jmp back to the function. For example,

 0000000000400c00 <main.main>: 400c00: 64 48 8b 0c 25 f0 ff mov %fs:0xfffffffffffffff0,%rcx 400c07: ff ff ... 400c4b: 48 83 7c 24 48 00 cmpq $0x0,0x48(%rsp) 400c51: 74 59 je 400cac <main.main+0xac> 400c53: 48 c7 04 24 c0 fc 47 movq $0x47fcc0,(%rsp) 400c5a: 00 ... 400cab: c3 retq 400cac: 89 04 25 00 00 00 00 mov %eax,0x0 400cb3: eb 9e jmp 400c53 <main.main+0x53> 

Is this some kind of trick that plays? If so, how does it work? I assume that at 0x400c51 it goes to 0x400cac , starts a SIGSEGV , which is being processed, and then the next instruction returns to 0x400c53 .

Answer 1

I got answers from Go developers: https://groups.google.com/forum/#!topic/golang-nuts/_7yio3ZfVBE

Basically, this pattern is a nil check in an obsolete implementation. Keith Randall's answer is quoted.

If the pointer is zero, it proceeds to the instruction that generates the malfunction. This error is used to trigger the nil ptr panic.

This is a rather inefficient code sequence. Jmps never seems to be used. Go to the newer version of Go and you will see that it has been improved.