It doesn't.
Fixes 386 build.
While we're here, mark runtime.asmcgocall as GO_ARGS,
so that it will work with stack copying. I don't think anything
that uses it can lead to a stack copy, but better safe than sorry.
Certainly the runtime.asmcgocall_errno variant needs
(and already has) GO_ARGS.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/
138400043
// aligned appropriately for the gcc ABI.
// See cgocall.c for more details.
TEXT runtime·asmcgocall(SB),NOSPLIT,$0-8
+ GO_ARGS
MOVL fn+0(FP), AX
MOVL arg+4(FP), BX
CALL asmcgocall<>(SB)
MOVL AX, ret+8(FP)
RET
-TEXT asmcgocall<>(SB),NOSPLIT,$0-12
+TEXT asmcgocall<>(SB),NOSPLIT,$0-0
// fn in AX, arg in BX
MOVL SP, DX
// aligned appropriately for the gcc ABI.
// See cgocall.c for more details.
TEXT runtime·asmcgocall(SB),NOSPLIT,$0-16
+ GO_ARGS
MOVQ fn+0(FP), AX
MOVQ arg+8(FP), BX
CALL asmcgocall<>(SB)
// aligned appropriately for the gcc ABI.
// See cgocall.c for more details.
TEXT runtime·asmcgocall(SB),NOSPLIT,$0-8
+ GO_ARGS
MOVW fn+0(FP), R1
MOVW arg+4(FP), R0
BL asmcgocall<>(SB)