Re: Status of 386 and arm ports for darwin

[Aaron Jacobs]

+golang-dev (maybe golang-nuts was the wrong choice)

On Mon, Aug 31, 2015 at 2:15 PM, Aaron Jacobs <jac...@google.com> wrote:
> Hi all,
>
> I'm attempting to fix up the autogenerated syscall-related files in
> golang.org/x/sys/unix. The darwin/386 and darwin/arm ports are giving me a bit
> of grief, in that I can't find any way to generate code for them on a modern
> Mac (which seems like an unhealthy place to be if it's not just my failing).
>
> Can anybody help me with a bit of context on these questions?
>
> 1. https://golang.org/doc/install doesn't list 386 support for darwin. I assume
> this port used to be supported but no longer is, given that Apple stopped
> selling 32-bit Macs awhile ago. Does it make sense to remove support for this
> in golang.org/x/sys/unix? That may not be as bad as it sounds, since the
> standard library syscall package would still presumably support the port.
>
> 2. What is the difference between the arm and arm64 ports -- is it a matter of
> 32-bit vs. 64-bit iOS devices? If so, is there a way to install a 32-bit iOS
> SDK for regenerating the files for darwin/arm on a modern Mac? (If not: same
> question as above about dropping support.)
>
> Thanks,
> Aaron

[minux]

On Mon, Aug 31, 2015 at 12:15 AM, 'Aaron Jacobs' via golang-nuts <golan...@googlegroups.com> wrote:

1. https://golang.org/doc/install doesn't list 386 support for darwin. I assume
this port used to be supported but no longer is, given that Apple stopped
selling 32-bit Macs awhile ago. Does it make sense to remove support for this
in golang.org/x/sys/unix? That may not be as bad as it sounds, since the
standard library syscall package would still presumably support the port.

I think we can treat it the same as how we treat OS X 10.6. Leave the code in,

but don't maintain it anymore.

2. What is the difference between the arm and arm64 ports -- is it a matter of
32-bit vs. 64-bit iOS devices? If so, is there a way to install a 32-bit iOS
SDK for regenerating the files for darwin/arm on a modern Mac? (If not: same
question as above about dropping support.)

Yes, darwin/arm is for 32-bit iOS devices. As not all iDevices are 64-bit capable,

I think we should still support darwin/arm for a little longer. We can stop maintaining

it once Apple abandons 32-bit iDevices officially.

To iOS SDK should contain headers for both darwin/arm and darwin/arm64 (actually

they are using the same copy of headers), and clang takes -arch parameter to

signify which platform you're targeting.

[Aaron Jacobs]

On Tue, Sep 1, 2015 at 2:30 PM, minux <mi...@golang.org> wrote:
> I think we can treat it the same as how we treat OS X 10.6. Leave the
> code in, but don't maintain it anymore.

I agree with this philosophy, except where it gets in the way of maintaining
the other architectures.

For example, I'm trying to fix up some weirdness around the constant
SYS___SYSCALL, which was renamed to SYS_SYCALL in OS X 10.10. For all of the
modern architectures I can just regenerate the code and get the new constant.
But if 386 hangs around, I need to play around with build tags and file names
to get the equivalent of "darwin_everything_but_386.go", making the package
even more confusing than it already is.

I wouldn't argue this point at all except that the package is almost entirely
redundant with package syscall, which would still be around for 386, especially
for old versions of the OS.

> Yes, darwin/arm is for 32-bit iOS devices. As not all iDevices are 64-bit
> capable,
> I think we should still support darwin/arm for a little longer. We can stop
> maintaining
> it once Apple abandons 32-bit iDevices officially.
>
> To iOS SDK should contain headers for both darwin/arm and darwin/arm64
> (actually
> they are using the same copy of headers), and clang takes -arch parameter to
> signify which platform you're targeting.

Thanks. Can you tell me exactly how to invoke mkall.sh for darwin/arm, which
you presumably did for commit 785372d? I can't make it work.

[minux]

On Tue, Sep 1, 2015 at 1:09 AM, Aaron Jacobs <jac...@google.com> wrote:

On Tue, Sep 1, 2015 at 2:30 PM, minux <mi...@golang.org> wrote:
> I think we can treat it the same as how we treat OS X 10.6. Leave the
> code in, but don't maintain it anymore.

I agree with this philosophy, except where it gets in the way of maintaining
the other architectures.

For example, I'm trying to fix up some weirdness around the constant
SYS___SYSCALL, which was renamed to SYS_SYCALL in OS X 10.10. For all of the
modern architectures I can just regenerate the code and get the new constant.
But if 386 hangs around, I need to play around with build tags and file names
to get the equivalent of "darwin_everything_but_386.go", making the package
even more confusing than it already is.

so the problem really is that mkall.sh doesn't work for 32-bit Darwin platforms?

What exactly are the problems?

Right now, I don't have 10.10 SDK installed, and running mkall.sh for both 386

and amd64 fails with cgo unable to determine the types of two constants

(C.SIOCGETSGCNT and C.SIOCGETVIFCNT)

I think we could figure out what is broken for 386 then then tackle arm.

Thanks. Can you tell me exactly how to invoke mkall.sh for darwin/arm, which
you presumably did for commit 785372d? I can't make it work.

I think I generated those files natively on an iPad with a native toolchain I built.

(I have one available here: https://bitbucket.org/minux/goios/downloads/iossdk-c-only-v2.tar.bz2

but that's only used to generate the darwin/arm64 files)

[Aaron Jacobs]

On Tue, Sep 1, 2015 at 5:02 PM, minux <mi...@golang.org> wrote:
> so the problem really is that mkall.sh doesn't work for 32-bit Darwin
> platforms? What exactly are the problems? Right now, I don't
> have 10.10 SDK installed, and running mkall.sh for both 386 and
> amd64 fails with cgo unable to determine the types of two constants
> (C.SIOCGETSGCNT and C.SIOCGETVIFCNT)

Thanks for prodding me to look at this again. darwin/386 doesn't fail as hard
as darwin/arm; the only issue is that /usr/include/sys/syscall.h doesn't exist.
If I instead point it at the OS X 10.10 SDK (as I did for amd64 in commit
e3fe6f5), it works. I had thought it would be a bad idea to do this because I
don't think that SDK is meant to work with 32-bit machines, but I guess the
syscall numbers aren't likely to vary.

So okay, forget my objections to darwin/386. I'm still chasing darwin/arm,
though.

> I think I generated those files natively on an iPad with
> a native toolchain I built. (I have one available here:
> https://bitbucket.org/minux/goios/downloads/iossdk-c-only-v2.tar.bz2
> but that's only used to generate the darwin/arm64 files)

Sorry, can you give from-scratch instructions on how to reproduce this? I'm
hoping to get the package into a state where anyone can just run the script and
get the same output.

[David Crawshaw]

It's true that darwin/x86 is uncommon. I have some interest in it, as
the iOS simulator uses darwin/x86 binaries when Xcode projects are set
to build 32-bit iOS apps (the default). So I intend to give it some
time this cycle to get -buildmode=c-archive working if I can get out
from under my email. But it is hard to think of it as important, as I
believe all shipping Apple x86 hardware is 64-bit.

As it is still normal to ship 32-bit arm binaries with iOS apps I
intend to keep supporting darwin/arm. I'm also a little worried about
counting it out. While I'm sure everyone prefers working on arm64, arm
may have power advantages in some places that see it come back.

I'll should be able to get a builder back online for darwin/x86 today.
(CL went in a while ago and the hardware is here, I just haven't dug
up my notes about how to push a new farmer.golang.org yet.)

> --
> You received this message because you are subscribed to the Google Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Russ Cox]

darwin/386 is important to developers of the compilers who work on Macs, because it means they can test GOARCH=386 without needing to find a second machine. I hope to keep it working on recent OS X versions for as long as possible.

Russ

[Aaron Jacobs]

This makes sense. I wound up making darwin/386 fly, so I withdraw any
suggestion about deleting anything related to it.

The only issue that continues to vex me is this error from cgo for darwin/arm
(your input appreciated if you have any idea what's going on):

https://github.com/golang/go/issues/12442