summaryrefslogtreecommitdiffhomepage
path: root/pkg/safecopy/memcpy_arm64.s
diff options
context:
space:
mode:
authorMichael Pratt <mpratt@google.com>2021-04-14 14:12:08 -0700
committergVisor bot <gvisor-bot@google.com>2021-04-14 14:14:21 -0700
commit108410638aa8480e82933870ba8279133f543d2b (patch)
treeb989ff6e85cc0ea29a3dab5a3f2306498ab47d0a /pkg/safecopy/memcpy_arm64.s
parent272d2e1168733fa7707ad21fca6f7a847f34bf1b (diff)
Use assembly stub to take the address of assembly functions
Go 1.17 is adding a new register-based calling convention [1] ("ABIInternal"), which used is when calling between Go functions. Assembly functions are still written using the old ABI ("ABI0"). That is, they still accept arguments on the stack, and pass arguments to other functions on the stack. The call rules look approximately like this: 1. Direct call from Go function to Go function: compiler emits direct ABIInternal call. 2. Indirect call from Go function to Go function: compiler emits indirect ABIInternal call. 3. Direct call from Go function to assembly function: compiler emits direct ABI0 call. 4. Indirect call from Go function to assembly function: compiler emits indirect ABIInternal call to ABI conversion wrapper function. 5. Direct or indirect call from assembly function to assembly function: assembly/linker emits call to original ABI0 function. 6. Direct or indirect call from assembly function to Go function: assembly/linker emits ABI0 call to ABI conversion wrapper function. Case 4 is the interesting one here. Since the compiler can't know the ABI of an indirect call, all indirect calls are made with ABIInternal. In order to support indirect ABI0 assembly function calls, a wrapper is generated that translates ABIInternal arguments to ABI0 arguments, calls the target function, and then converts results back. When the address of an ABI0 function is taken from Go code, it evaluates to the address of this wrapper function rather than the target function so that later indirect calls will work as expected. This is normally fine, but gVisor does more than just call some of the assembly functions we take the address of: either noting the start and end address for future reference from a signal handler (safecopy), or copying the function text to a new mapping (platforms). Both of these fail with wrappers enabled (currently, this is Go tip with GOEXPERIMENT=regabiwrappers) because these operations end up operating on the wrapper instead of the target function. We work around this issue by taking advantage of case 5: references to assembly symbols from other assembly functions resolve directly to the desired target symbol. Thus, rather than using reflect to get the address of a Go reference to the functions, we create assembly stubs that return the address of the function. This approach works just as well on current versions of Go, so the change can be made immediately and doesn't require any build tags. [1] https://go.googlesource.com/go/+/refs/heads/master/src/cmd/compile/abi-internal.md PiperOrigin-RevId: 368505655
Diffstat (limited to 'pkg/safecopy/memcpy_arm64.s')
-rw-r--r--pkg/safecopy/memcpy_arm64.s6
1 files changed, 6 insertions, 0 deletions
diff --git a/pkg/safecopy/memcpy_arm64.s b/pkg/safecopy/memcpy_arm64.s
index e7e541565..7b3f50aa5 100644
--- a/pkg/safecopy/memcpy_arm64.s
+++ b/pkg/safecopy/memcpy_arm64.s
@@ -76,3 +76,9 @@ forwardtailloop:
CMP R3, R9
BNE forwardtailloop
RET
+
+// func addrOfMemcpy() uintptr
+TEXT ·addrOfMemcpy(SB), $0-8
+ MOVD $·memcpy(SB), R0
+ MOVD R0, ret+0(FP)
+ RET