uname -m reports x86_64 on arm64 systems

[invertego]

uname -m is expected to report the host machine's CPU architecture. Some existing build scripts/makefiles depend on it to detect the host architecture (example) and often use it for the assumed target architecture.

Because msys2-runtime is built only as x86_64 and runs on arm64 under emulation, uname will always report x86_64. Furthermore, it currently lacks the logic to report any string other than "x86_64" and " unknown":

msys2-runtime/winsup/cygwin/uname.cc

Lines 66 to 74 in f992cbc

	switch (wincap.cpu_arch ())
	{
	case PROCESSOR_ARCHITECTURE_AMD64:
	strcpy (name->machine, "x86_64");
	break;
	default:
	strcpy (name->machine, "unknown");
	break;
	}

I believe aarch64 would be the appropriate string to use on Win/arm64 systems for consistency with other OSes.

[dscho]

There is no native MSYS2 runtime that supports ARM64. What you are running is an x86_64 MSYS2 runtime, running in emulation mode. Therefore the uname -m is actually correct: the emulation pretends to run on an x86_64 processor.

[invertego]

That is indeed what I meant by "Because msys2-runtime is built only as x86_64 and runs on arm64 under emulation".

It's undesirable behavior, specifically in the clangarm64 environment where everything in the compiler toolchain is a native arm64 executable and targets arm64 by default. The pertinent question is whether the solution is a native arm64 build of msys2-runtime or something simpler in the interim (lazka was considering having uname follow the MSYSTEM environment variable).

[dscho]

Lying about the CPU architecture the MSYS2 runtime is running on might help some use cases, but totally break others. That's worse than undesirable, that would be willful.

The proper solution is to build an ARM64 version of the MSYS2 runtime.

The problem with that is that it is currently impossible, and it will take years to finish that work.

BTW for many scenarios, looking at MSYSTEM and only using uname -m as a fall-back is something worth considering, as it does not share the downsides of the proposed solution to change uname -m.

[mati865]

Corss-posting to keep the information at one place, I stand by what I have previously said on Discord:

It doesn't seem right, if some x86_64 binary from /usr/bin (because it's x86_64 "system" after all, just emulated) calls uname and sees AArch64 it can do unexpected things.
It's like running x86_64 Linux via QEMU on AArch64, it would still print x86_64.

I think the correct and non-invasive solution would be to check MSYSTEM in Makefile.

[jeremyd2019]

(lazka was considering having uname follow the MSYSTEM environment variable).

uname -s follows MSYSTEM, more or less - it used to contain it verbatim but enough things (autoconf) were confused by new values that it is now constrained to MINGW32 or MINGW64 based on whether the MSYSTEM has 32 or 64.

I agree that uname -m should rightly return x86_64 - much like the prior 32-bit msys2 would return i686 even if running on a 64-bit Windows (WoW64). Once Cygwin supports ARM64 (which is indeed a large project, which first needs binutils and gcc support, work is happening in that area) another case should be added to that switch as part of that support.

[invertego]

I'm glad we all agree that an arm64 native build of msys2-runtime would resolve this issue.

The problem with that is that it is currently impossible, and it will take years to finish that work.

What @Blackhex said in Discord implied this was closer to happening. You appear to share an employer; maybe you could share notes?

Regarding alternatives, I'll just say that if binaries compiled in a clangarm64 environment depended on msys2-runtime in any way, the argument for keeping things as-is would be obvious. But they don't, so the principle in defense here remains mysterious to me.

[dscho]

I'm glad we all agree that an arm64 native build of msys2-runtime would resolve this issue.

So. Are you working on this? Maybe you did not hear me when I essentially explained that you're asking for the moon here.

The problem with that is that it is currently impossible, and it will take years to finish that work.

What @Blackhex said in Discord implied this was closer to happening.

Work is currently underway to support Windows/ARM64 in binutils. That is a huge undertaking. And it is only the first step of many to get gcc to work. And that's only a prerequisite to getting a Cygwin-compatible gcc/binutils to work. And once that is done, another huge step will be to get the Cygwin runtime with all of its hacks to work (e.g. the current directory hack, AKA FAST_CWD hack). And once that is done, you can target the MSYS2 part, which will be involved, too, in particular the bootstrapping part.

And now that you have a glimpse of what you were actually asking for (an effort easily keeping a decently-sized team of top notch experts busy for years), maybe you can agree with the rest of us that looking at MSYSTEM before looking at uname -m for the sake of clang-aarch64 is not such a fantastically bad idea after all?

[invertego]

I only filed this issue because @lazka specifically requested that I do so. If you have further questions, take them to him.

[invertego]

Let's try this one more time.

For the use case of someone compiling software for arm64 on an arm64 machine using msys2 and clangarm64 packages, the (virtualized) environment that uname runs in is not paramount. The true architecture of the host CPU is a more relevant than the architecture that uname was compiled for. I understand that there must be other use cases for which that information is still relevant, which is why I haven't argued it should simply always report the native machine returned by IsWow64Process2.

I understand that having an arm64 msys runtime would mostly make this go away, but that's actually not my preferred solution because of the work involved and because, again, the arch that the runtime was compiled for is really not relevant to my use case. Far from insisting or demanding that this work be done, I was simply acknowledging that this work would have the side effect of alleviating the issue.

I do not prefer the solution of asking every individual project to update their makefiles to check MSYSTEM because it fails the test of allowing msys2 to function as drop-in replacement for compiling in a Unix-like environment. Some project maintainers outright resent having to put checks in their build systems that are Windows-specific. I'm sure you are all well aware of this, however, which is why I didn't think it was necessary for me to spell it out.

If having the behavior of uname depend on MSYSTEM and report aarch64 in the clangarm64 environment (which was, again, lazka's suggestion and not my own) was viewed as acceptable, I wouldn't mind putting forth a PR. But the reaction to that seems to have been quite negative, and since nobody else is offering suggestions, it's not clear what else I can do to help.

[lazka]

I've only every have seen uname being used in a build context, which in the clangarm64 case will always mean mingw builds since we don't support cygwin builds in those envs anyway. So such a hack seemed maybe worth it to me, but I might be missing something.

On the other hand we've never had many problems with our existing packages being confused by uname, likely because most use a proper build system, and not just make, so I don't feel strongly about this.