Check `//go:linkname` usage

Operating System

What feature would you like to be added?

Why is this needed?

We want purego to continue to work

For our runtime.cgocall, which we pulled, would syscall_cgocaller be available instead?

https://cs.opensource.google/go/go/+/master:src/runtime/cgocall.go;l=110;drc=9fa34d9fa25078423cdb484d39cdd62f067098ac?q=runtime%20cgocall&ss=go%2Fgo

For our runtime.cgocall, which we pulled, would syscall_cgocaller be available instead?

Perhaps for purego.SyscallN but not RegisterFunc since it needs the entire struct since any type of value could be returned

Although this line isn't using //go:linkname perhaps we should make it one so that this function stays around?

purego/internal/fakecgo/asm_amd64.s

Line 35 in 6cd1224

CALL runtime·cgocallback(SB)

Another possible solution is to just prebuild runtime/cgo for each GOOS,GOARCH, and GOVERSION pair that purego supports into a cgo_GOOS_GOARCH_GOVERSION.syso file. I'm not sure that'll work but it would limit the amount of //go:linkname to just runtime.cgocall and means any changes to the runtime/cgo package would already be included. The hard part is trying to make the builds reproducible. I remember we tried for something else and eventually gave up.

Of course it is ideal to have reproducible builds, but if there is no other way, we would have to allow such builds...

Of course it is ideal to have reproducible builds, but if there is no other way, we would have to allow such builds...

Are you saying you are in favor of using a prebuilt binary instead of maintaining our own Go port of runtime/cgo?

Of course, I still need to test to make sure this will work

Are you saying you are in favor of using a prebuilt binary instead of maintaining our own Go port of runtime/cgo?

No, I mean, it is ok-ish to allow non-reproducible binaries if there is no other way. I have no idea which way is better so far.

I think we should move away from using as many linkname comments. It'll hopefully make the code easier to understand and avoid any future breakage. Right now I don't believe purego will break with Go 1.23 but I should try with the go tip as the linkname and required handshake have now made it into tip.

I suggest removing at least the following linkname:

Noescape: inline this function
Playground: replace with an actual implementation that gives a nice panic
Cgocallback: make it explicit that we depend on this function with a linkname instead of calling it directly

@hajimehoshi I don't think there is anything left to do for this issue. Agree to close it?

Don't we still use some unexported APIs?

Don't we still use some unexported APIs?

Yes but none of those can be removed without breaking purego. Unless the Go team wants to rewrite runtime/cgo to only use Go we are stuck with those.

Sure!