Go: proposal: doc: document that Go 1.14 is last to support darwin/arm (32bit version)?

[dmitshur]

iOS 13 (and iPadOS 13) does not support running 32-bit apps. iOS 10 was the last version that supported 32-bit apps (with very visible warnings), and it's 3 years old.

Is it time to remove darwin/arm (leaving just darwin/arm64)? If so, the first step would be to document that Go 1.14 will be the final release with darwin/arm support.

Related to #34749. /cc @bradfitz @hyangah @eliasnaur

[eliasnaur]

Other than the builder, darwin/arm support isn't too much extra hassle than just darwin/arm64.

Go runs on watchOS and tvOS now, and the first darwin/arm64 watch (Watch Series 4) was released just a year ago. Earlier models are 32-bit.

@steeve might care; he had reservations last time I asked. Steeve also runs the hardware darwin/arm builder which has been offline for quite a while.

[bradfitz]

Not having a builder is another good reason to delete it.

That's actually our official policy: https://github.com/golang/go/wiki/PortingPolicy#removing-a-port

[dmitshur]

Thanks for providing that information Elias. I was thinking about watchOS and tvOS but wasn't sure what the state of their 32->64-bit migration was.

From looking over https://en.wikipedia.org/wiki/Apple_TV, I understand the current Apple TV devices (4th and 5th generations) support 64-bit (only?), but 3rd generation (released in 2013, discontinued in 2016) did not.

It sounds like watchOS devices aren't as far along, but iOS/iPadOS and tvOS are.

[steeve]

We are planning on removing arm support in a few weeks/months (most likely when we migrate to xcode 11). Although not just yet.

Supporting older WatchOS hardware looks like a pretty good reason to keep it though since it can now run Go (and I mean, how cool is that), which is fairly new with 1.13.

The builder being off-line is on me though, I'll fix that tomorrow morning.

[eliasnaur]

@dmitshur, I briefly considered AppleTV. Only the 4th generation support the App Store, so we don't need 32-bit support for AppleTV.

[steeve]

I have restarted the darwin_arm and darwin_arm64 builders. 🤞

[eliasnaur]

I have restarted the darwin_arm and darwin_arm64 builders. crossed_fingers

If only it was that easy: https://farmer.golang.org/temporarylogs?name=darwin-arm64-mn4m2zdaios&rev=cedb561617ea40c72dc018b38c4d5f0862595fe8&st=0xc0020f51e0

ERROR: Could not connect to lockdownd, error code -21

[steeve]

ERROR: Could not connect to lockdownd, error code -21

Alas, libimobiledevice needed an update, and somehow one of the iPhones wouldn't pair with the computer unless itunes was launched. Should be good now.

EDIT: it wasn't good, missing env vars. Should be better now.

[eliasnaur]

Still no luck:

error: The specified item could not be found in the keychain.
go_darwin_arm_exec: codesign: exit status 1
FAIL    bytes   0.277s

[steeve]

Yes saw that. I'm on it.

[steeve]

Still working on it, now with new errors:

Install: VerifyingApplication (40%)ERROR: Install failed. Got error "ApplicationVerificationFailed" with code 0xe8008015: Failed to verify code signature of /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.UKJYBy/extracted/gotest.app : 0xe8008015 (A valid provisioning profile for this executable was not found.)
go_darwin_arm_exec: ideviceinstaller -i "/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/tmp/go_darwin_arm_exec_352375303/gotest.app": exit status 128 (5 attempts)
FAIL    html    274.599s

[eliasnaur]

For errors like that I usually created a scratch project in Xcode, filled in the team and bundle ID from the GOIOS_* environment variables and made sure I could run the project on the device.

[steeve]

@eliasnaur Yes, I forgot to regenerate the provisioning profile after recreating the development certificate.

New error though, which I'm kinda clueless in https://farmer.golang.org/temporarylogs?name=darwin-arm-mg912baios&rev=ce83f41fed32bfc7826ec0cd7756a34594f8746b&st=0xc00c7d02c0:

*** Test killed with quit: ran too long (19m0s).
FAIL    compress/gzip   1140.013s

I see the app on the device, although I don't see it starting.

[steeve]

Also, I don't see the development images mounted on the devices

[eliasnaur]

@eliasnaur Yes, I forgot to regenerate the provisioning profile after recreating the development certificate.

New error though, which I'm kinda clueless in https://farmer.golang.org/temporarylogs?name=darwin-arm-mg912baios&rev=ce83f41fed32bfc7826ec0cd7756a34594f8746b&st=0xc00c7d02c0:

*** Test killed with quit: ran too long (19m0s).
FAIL  compress/gzip   1140.013s

I see the app on the device, although I don't see it starting.

The wrapper times out while waiting on misc/ios/go_darwin_arm_exec.go:443, which is the ideviceinstall -i command. I don't know why.

You could try to kill the builder and run all.bash manually, as described in misc/ios/README. You did the hard work already, so hopefully

$ GOIOS_DEVICE_ID=8e5c23a5d0843d1ffe164ea0b2f2500599c3ebff GOARCH=arm64 CGO_ENABLED=1 CC_FOR_TARGET=$(pwd)/../misc/ios/clangwrap.sh ./all.bash

reproduces the hang.

EDIT: Alternatively, use make.bash above and run

$ export PATH=$GOROOT/bin:$PATH        # to add the exec wrapper to PATH
$ GOIOS_DEVICE_ID=8e5c23a5d0843d1ffe164ea0b2f2500599c3ebff GOARCH=arm64 CGO_ENABLED=1 go test -v archive/tar

to see debug output from the wrapper.

There is also a debug bool in misc/ios/go_darwin_arm_exec.go that you could flip before make.bash.

[steeve]

Yes, running it manually, I see it signing the binary, then running ideviceinstaller (doesn't show up in the console though, I'm seeing it because the app appears on the device).

[steeve]

Ok I got a repro: ideviceinstaller is stuck on GeneratingApplicationMap. Digging.

[steeve]

Somehow it's working fine on the arm64 device. I have tried to reset the arm device, no luck. I'll try another device tomorrow. In the mean time the arm64 builder should be back online.

[steeve]

The last build is failed for what looks like legitimate failures

[steeve]

For the record:

lldb: running program
panic: open /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/reflect: no such file or directory

goroutine 49 [running]:
internal/reflectlite_test.loadTypes(0x1300b4310, 0x6b, 0x100e258fe, 0x7, 0x1300b08a0)
    /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/internal/reflectlite/reflect_mirror_test.go:79 +0x130
internal/reflectlite_test.TestMirrorWithReflect.func1(0x1300b8ce0, 0x1300b4310, 0x6b, 0x100e258fe, 0x7, 0x1300b08a0)
    /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/internal/reflectlite/reflect_mirror_test.go:104 +0x70
created by internal/reflectlite_test.TestMirrorWithReflect
    /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/internal/reflectlite/reflect_mirror_test.go:102 +0x1e0
FAIL    internal/reflectlite    29.700s

And (more obscure):

lldb: running program
FAIL    runtime 37.602s

[eliasnaur]

For the record:

lldb: running program
panic: open /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/reflect: no such file or directory

goroutine 49 [running]:
internal/reflectlite_test.loadTypes(0x1300b4310, 0x6b, 0x100e258fe, 0x7, 0x1300b08a0)
  /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/internal/reflectlite/reflect_mirror_test.go:79 +0x130
internal/reflectlite_test.TestMirrorWithReflect.func1(0x1300b8ce0, 0x1300b4310, 0x6b, 0x100e258fe, 0x7, 0x1300b08a0)
  /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/internal/reflectlite/reflect_mirror_test.go:104 +0x70
created by internal/reflectlite_test.TestMirrorWithReflect
  /private/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/go/src/internal/reflectlite/reflect_mirror_test.go:102 +0x1e0
FAIL  internal/reflectlite    29.700s

This tests seems to load files which are not available on the tethered setup. It should probably just be skipped.

And (more obscure):

lldb: running program
FAIL  runtime 37.602s

After running make.bash, running the runtime tests in verbose mode should be as easy as

  export PATH=$GOROOT/bin:$PATH
  GOIOS_DEVICE_ID=... GOARCH=arm64 CGO_ENABLED=1 go test -v runtime

Perhaps additional -run <pattern>s might tease out the offending test.

[eliasnaur]

Perhaps we should move the discussion to https://golang.org/issue/34847.

[bcmills]

Let's move the builder discussion to #31497, assuming those are still the builders we intend to use.

[bradfitz]

@steeve, you wrote:

We are planning on removing arm support in a few weeks/months (most likely when we migrate to xcode 11). Although not just yet.

Supporting older WatchOS hardware looks like a pretty good reason to keep it though since it can now run Go (and I mean, how cool is that), which is fairly new with 1.13.

Is that a yes or no no removing darwin/arm after Go 1.14?

This is all dependent on builders staying up, so is it worth it to you, given that you're the one running the builders nowadays?

[bradfitz]

(ping @steeve; auto-completed messed up your handle earlier)

[steeve]

@bradfitz I'm sort of glad to announce that we no longer ship darwin/arm. That said, I'm happy to keep the builders up if that helps (ie "old" WatchOS support).

Not that I'll able to dig into why the tests fail (as they are now), but if I'm pinged when they go down (because they are fragile), I can have them up in a few days max.

[bradfitz]

How about we hedge a bit and announce that "Go 1.14 is likely the last release to support 32-bit darwin/arm but 64-bit darwin/arm64 support is unaffected" and see if anybody peeps up with concerns?

Then if our builders prove too difficult to keep up we can remove it, but if they're not causing us problems, we could keep it around a bit longer.

Any objections?

[bcmills]

That seems OK to me, with the proviso that I would want to set the bar for “too difficult to keep up” very low.

If we need to make any significant changes for darwin/arm that aren't necessary for — or at least easily derivable from — darwin/arm64 or some other supported arm platform, we should bias toward removing support rather than spending time on maintenance.

[steeve]

I think this is a good idea.

[gopherbot]

Change https://golang.org/cl/203879 mentions this issue: doc/go1.14: document that Go 1.14 is likely last to support darwin/arm