What is a context register and how does it change the way Go code is compiled?
Context: I've seen uses of stub functions in some parts of GOROOT, i.e. reflect, but am not quite sure how these work.
The expression "context register" first appeared in commit b1b67a3 (Feb. 2013, Go 1.1rc2) for implementing step 3 of the Go 1.1 Function Calls
Change the
reflect.MakeFuncimplementation to avoid run-time code generation as well
It was picked up in commit 4a000b9 in Feb. 2014, Go 1.3beta1, for assembly and system calls for Native Client x86-64, where sigreturn is managed as:
NaClhas abidcated its traditional operating system responsibility and declined to implement 'sigreturn'.
Instead the only way to return to the execution of our program is to restore the registers ourselves.Unfortunately, that is impossible to do with strict fidelity, because there is no way to do the final update of PC that ends the sequence without either
- (1) jumping to a register, in which case the register ends holding the PC value instead of its intended value, or
- (2) storing the
PCon the stack and usingRET, which imposes the requirement thatSPis valid and that is okay to smash the word below it.The second would normally be the lesser of the two evils, except that on NaCl, the linker must rewrite
RETinto "POP reg; AND $~31, reg; JMP reg", so either way we are going to lose a register as a result of the incoming signal.Similarly, there is no way to restore
EFLAGS; the usual way is to usePOPFL, butNaClrejects that instruction.
We could inspect the bits and execute a sequence of instructions designed to recreate those flag settings, but that's a lot of work.Thankfully, Go's signal handlers never try to return directly to the executing code, so all the registers and
EFLAGSare dead and can be smashed.
The only registers that matter are the ones that are setting up for the simulated call that the signal handler has created.
Today those registers are justPCandSP, but in case additional registers are relevant in the future (for exampleDXis the Go funccontext register) we restore as many registers as possible.
Much more recently (Q4 2016), for Go 1.8, we have commit d5bd797 and commit bf9c71c, for eliminating stack rescanning:
morestackwrites the context pointer togobuf.ctxt, but sincemorestackis written in assembly (and has to be very careful with state), it does not invoke the requisite write barrier for this write. Instead, we patch this up later, innewstack, where we invoke an explicit write barrier for ctxt.This already requires some subtle reasoning, and it's going to get a lot hairier with the hybrid barrier.
Fix this by simplifying the whole mechanism.
Instead of writinggobuf.ctxtinmorestack, just pass the value of the context register tonewstackand let it write it togobuf.ctxt. This is a normal Go pointer write, so it gets the normal Go write barrier. No subtle reasoning required.