syscall: SyscallN always escapes the variadic argument

[qmuntal]

Go version

go version devel go1.24-bea9b91f0f Tue Nov 5 01:16:03 2024 +0000 windows/amd64

What did you do?

Run go build -gcflags=-m .

package main

import (
	"syscall"
	"unsafe"
)

var sink byte
var procProcessPrng = syscall.NewLazyDLL("bcryptprimitives.dll").NewProc("ProcessPrng").Addr()

func main() {
	var buf [10]byte
	syscall.SyscallN(procProcessPrng, uintptr(unsafe.Pointer(&buf[0])), uintptr(len(buf)))
	sink ^= buf[0]
}

What did you see happen?

The syscall.SyscallN variadic argument escaped to the heap.

./main.go:13:18: ... argument escapes to heap

What did you expect to see?

The syscall.SyscallN variadic argument didn't escape to the heap, just as other syscall.SyscalX functions.

./main.go:13:18: ... argument does not escape

Note that syscall.SyscallN is implemented by runtime.syscall_syscalln, which makes sure that the variadic argument doesn't escape:

go/src/runtime/syscall_windows.go

Line 519 in bea9b91

c.args = uintptr(noescape(unsafe.Pointer(&args[0])))

@golang/compiler @golang/windows

[gabyhelp]

Related Issues and Documentation

• syscall: add SyscallN
• syscall: (*LazyProc).Call does not keep arguments alive (anymore) #34474 (closed)
• x/sys/windows/mkwinsyscall: generates invalid calls for GOARCH=386 #42373
• syscall: panic making syscall if windows.Handle is used instead of uintptr #31825 (closed)
• cmd/compile: recognize Syscall-like functions for liveness analysis
• syscall/exec_windows.go: appendEscapeArg does not escape all necessary characters #68313 (closed)
• syscall: SysProcAttr{ NoInheritHandles: true } broken in 1.17 on Windows #48040 (closed)
• cmd/compile, syscall: add //go:uintptrescapes comment, and use it
• syscall: fix wrong unsafe.Pointer alignment in syscall
• cmd/cgo: make sure pointers passed to C escape to heap

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[qmuntal]

This issue is blocking the use of syscall.SyscallN in x/sys/windows/mkwinsyscall, see CL 623821.

[gopherbot]

Change https://go.dev/cl/625297 mentions this issue: syscall: mark SyscallN as noescape

[qmuntal]

@dmitshur @ianlancetaylor would it make sense to backport CL 623821 (if finally merged) to Go 1.22 and Go 1.23? This issue exists since the introduction of syscall.SyscallN in Go 1.17, but the alternatives (syscall.Syscall and friends) have been deprecated since then. I wouldn't want users to start switching back to the deprecated functions, as they are easier to misuse.

[dmitshur]

@qmuntal I'm a bit confused by the specifics in your question (maybe you got the wrong CL number mentioned? that one pulls in many x/sys CLs all at once), but in general, if there is a serious issue without a workaround and we can be confident the fix is narrow and safe, please create the backport issues with the rationale and we will consider it. See https://go.dev/wiki/MinorReleases#cherry-pick-cls-for-vendored-golangorgx-packages for details on a single x/sys CL can be backported to the vendored packages on 1.23/1.22 release branches.

[qmuntal]

I'm a bit confused by the specifics in your question (maybe you got the wrong CL number mentioned?

Wops, I linked the wrong CL. I was referring to 625297.

I'll create the backport issue, thanks for the pointer.

[qmuntal]

@gopherbot please open the backport tracking issues. syscall.SyscallN alternatives are deprecated, and there is the risk of users switching back to them if syscall.SyscallN is less performant.

[gopherbot]

Backport issue(s) opened: #70201 (for 1.22), #70202 (for 1.23).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.