chore: added Apple M1 platform detection when compiling with Rosetta 2

[kyr0]

This PR handles the special case when a developer is trying to compile on an Apple Silicon M1 machine with a toolchain that is dual-arch (arm64e and x86_64) which is a valid case when the build toolchain is x86_64 based and Rosetta 2 is active. In this case, the current configure.py is unable to figure out the correct host platform as the toolchain will just return x86_64 even if the true host arch is arm64.

The impl. in the commit is trying to keep the current logic as untouched as possible to prevent any regressions.

Fixes: #40302

[richardlau]

_LP64 is not arm64 specific so this is going to break non-arm 64-bit platforms.

[kyr0]

True, I just came to the same understanding while you were commenting. I wrote a sum-up of the issue in my updated PR desc.

[kyr0]

The true cause of the issue is that when we assume that the parsed output of e.g. ${CC_host} -dM -E - will contain the host arch at a specific index like we do here:

node/configure.py

Line 1072 in d23af0d

if i in k and k[i] != '0':

Just isn't there because the output of cc (in my case) is not standardized (as it seems) or other circumstances make the toolchain write stuff like _LP64 there instead of the host arch identifier... well, then we're going to assume the wrong host_arch here, trigger the cross-compilation, and v8 compilation will fail because it tries to compile the wrong inline assembly impl.

Any ideas? :)

[kyr0]

I could just put a special override if-condition to check for M1 as a platform instead of relying on the cc output but it is such a nice abstract impl, that it seems a bit hacky to do that. However, Node.js not being able to compile on M1 is quite a blocker... so maybe...

[kyr0]

Unfortunately, in the case of building with a fat binary, even running uname -p or uname -m gives me i386 and x86_64. This is probably because Rosetta2 emulates "I'm running on an x86_64 machine". There is only one way to escape this rabbit hole (as far as I can see atm): Running uname -v which gives us the kernel version string as Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:20 PDT 2021; root:xnu-7195.141.6~3/RELEASE_ARM64_T8101.

This off behaviour can not reproduced by running uname -p or uname -m on the command line of an M1 machine. It can only reproduced when the parent process that executes these shell commands is emulated via Rosetta.

As we can see, the uname -v kernel version string includes the ARM64 release tag which indicates that the kernel is actually running on an ARM platform and the toolchain is running as a universal binary, translated via Rosetta2.

[kyr0]

I now implemented this extra check using the uname -v approach; it is so specific that it def. shouldn't break other platforms: The probability that uname -v includes "Darwin" and "ARM64" should be 0 for any other platform than Apple / M1, right? Only in this case, the condition will trigger and override the wrong assumption that is just happening because the whole toolchain is in emulation mode (Rosetta)

[kyr0]

Could someone check if other types of error/exception could happen in other environments when uname is not available? I tried with different command names that are def. not available and the catch/forget code works well

[mscdex]

Instead of relying on uname, wouldn't a better solution to check the value of the sysctl sysctl.proc_translated if the platform is Darwin? If it gives a value of 1 then it's executing under Rosetta.

Apparently you can also query the macOS I/O registry to get the real underlying hardware, such as with ioreg -c IOPlatformDevice.

However should we really be supporting this? I don't own/use Apple hardware so I'm not familiar with Rosetta, but it seems like with a change like this we'd be implicitly cross compiling (with no way to create an x86 binary), which might be surprising?

[kyr0]

@mscdex Nice suggestions! Actually, it is a valid point that you raised; the default build target could also be x86_64 for Rosetta; but it would be nice (from my point of view) that if you're running Rosetta, it wouldn't crash at least, when you specify --dest-cpu=arm64; of course, to make this happen, I'd need to change my PR further to additionally check for the --dest-cpu flag as well. Or, as mentioned by me in the issue, we could also define this as an edge case and leave it as it is; but then, you cannot build arm64 on M1 when your build toolchain is "universal" which is also kinda counterintuitive that you can't build arm64 on an arm64 machine :)) But yeah, it's an edge case somehow; it doesn't affect most M1 users as most of them seem to not have a universal build toolchain installed. In case we close this, it would be at least nice to document the behavior I think.. other users could bump into this as well.

[AshCripps]

Blocking as I believe this will break our release builds and will need verifying.