internal/fakecgo on iOS: the two darwin_arm_init_* TODOs look like no-ops outside lldb builds — is _PUREGO_REQUIRES_CGO_ON_IOS still needed?

[pengyanai]

Question

I'd like to build for GOOS=ios with CGO_ENABLED=0, and I'm trying to work out whether the guard in is_ios.go is a hard constraint or a conservative placeholder.

internal/fakecgo/go_darwin.go has two //TODO: support ios blocks — threadentry() wants darwin_arm_init_thread_exception_port(), and x_cgo_init() wants that plus darwin_arm_init_mach_exception_handler() and init_working_dir().

Looking at how upstream runtime/cgo defines these, two of the three seem to matter less than the TODO suggests:

• gcc_signal_ios_arm64.c (which defines both darwin_arm_init_* functions) is gated //go:build lldb. The non-lldb variant, gcc_signal_ios_nolldb.c, is literally empty bodies for both. So outside lldb-driven test runs those are no-ops in the C path too — meaning the missing piece may not be exception handling at all.
• init_working_dir() is the one real gap: CFBundleGetMainBundle → CFBundleCopyResourceURL(Info.plist) → chdir to the bundle's parent. zsymbols_darwin.go currently imports no CoreFoundation symbols, so that would be the only new dependency.

The build tags don't look like the obstacle either — go/build's matchTag makes GOOS=ios also match darwin, so fakecgo's !cgo && darwin files already compile into an iOS build; only the explicit _PUREGO_REQUIRES_CGO_ON_IOS in is_ios.go stops it.

So:

1. Is _PUREGO_REQUIRES_CGO_ON_IOS currently a "not done yet" marker rather than a measured requirement?
2. If init_working_dir is the only real gap — is it even desirable for a library embedded in someone else's iOS app? It chdirs the host process to the Bundle root, which is a process-wide side effect; Go's comment notes the CWD otherwise starts at / on iOS. Not doing it may be the better behavior, which would make this smaller rather than larger.
3. Is there a known failure the TODO doesn't mention — pthread_sigmask/TLS specifics on iOS, main-thread constraints, or simply that CI has no GOOS=ios job (.github/workflows/test.yml covers windows/darwin/linux/freebsd/netbsd but not ios)?

Context: I'm porting a Go UI framework that drives AppKit through purego under the same no-cgo rule, and iOS is currently the one target that rule excludes. Your answer decides whether that's a temporary gap or a permanent boundary.

[TotallyGamerJet]

The issue is the Go compiler. It does not allow building iOS with CGO_ENABLED=0