patch, 6 partsSupport Windows/ARM64

Git for Windows has started building artifacts for Windows/ARM64 since v2.47.1 (November 25th 2024). Now that Windows/ARM64 GitHub Action runners are available in public preview [https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-available-in-public-preview/] at long last, it is high time to upstream the minimal set of patches to build Git on Windows/ARM64 and pass the test suite.

Dennis Ameling (2):
  bswap.h: add support for built-in bswap functions
  config.mak.uname: add support for clangarm64

Johannes Schindelin (4):
  mingw: do not use nedmalloc on Windows/ARM64
  msvc: do handle builds on Windows/ARM64
  mingw(arm64): do move the `/etc/git*` location
  max_tree_depth: lower it for clangarm64 on Windows

 compat/bswap.h   | 14 +++++++++++++-
 config.mak.uname | 18 ++++++++++++++----
 environment.c    | 12 ++++++++++++
 3 files changed, 39 insertions(+), 5 deletions(-)

base-commit: 683c54c999c301c2cd6f715c411407c413b1d84e
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1904%2Fdscho%2Fsupport-clangarm64-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1904/dscho/support-clangarm64-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1904

From: Dennis Ameling <dennis@dennisameling.com>

Newer compiler versions, like GCC 10 and Clang 12, have built-in functions for bswap32 and bswap64. This comes in handy, for example, when targeting CLANGARM64 on Windows, which would not be supported without this logic.

Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
---
 compat/bswap.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

From: Dennis Ameling <dennis@dennisameling.com>

CLANGARM64 is a relatively new MSYSTEM added by the MSYS2 team. In order to have Git build correctly for this platform, let's add some configuration for it to config.mak.uname.

Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
---
 config.mak.uname | 4 ++++
 1 file changed, 4 insertions(+)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

It does not compile there, and seeing as nedmalloc has been pretty much unmaintained since at least November 2017, as per https://github.com/ned14/nedmalloc/issues/20#issuecomment-343432314, there is also no hope that any fixes will materialize there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

On Mon, Apr 21, 2025 at 12:39:07PM +0000, Johannes Schindelin via GitGitGadget wrote:

This kind of raises the question whether we want to keep on maintaining nedmalloc in our codebase at all. Is there any strong reason to have it?

Patrick

Hi Patrick,

On Tue, 22 Apr 2025, Patrick Steinhardt wrote:

To the contrary, There is a very strong reason to drop it: nedmalloc is unmaintained.

There is just a teeny tiny blocker before it can be dropped, though:

$ git grep -n USE_NED_ALLOCATOR upstream/master -- ':(exclude)Makefile' upstream/master:config.mak.uname:478: # USE_NED_ALLOCATOR = YesPlease upstream/master:config.mak.uname:741: USE_NED_ALLOCATOR = YesPlease upstream/master:contrib/buildsystems/CMakeLists.txt:258: USE_NED_ALLOCATOR OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP

The commented-out one is the MSVC build (I had experimental Git for Windows patches to enable nedmalloc even in MSVC builds, which I abandoned in favor of https://github.com/git-for-windows/git/pull/4580 to enable mimalloc in MSVC builds, but I abandoned that effort, too, because Git decided to favor Meson over first-class MSVC support and I decided to focus on avoiding to have my time wasted by the Git project).

As you are quite aware (because it caused plenty of trouble with your reftable patch series), Git for Windows switched to mimalloc quite a while ago (https://github.com/microsoft/mimalloc).

When I switched Git for Windows to mimalloc, I did (re-)run a couple of performance tests to see whether having a custom allocator is still necessary, and from my (unfortunately too vague) recollection, Windows 11's default allocator seems to have performed quite well in comparison. Which is in stark contrast to the results of the performance tests I ran when originally integrating nedmalloc. So: In theory, Git for Windows could drop building with a custom allocator, iff it wasn't for older Windows version that are still supported.

Which means that I would like to upstream the vendored-in mimalloc first, with the patch to use it when building on Windows by default, before dropping nedmalloc from Git's source code.

Ciao, Johannes

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Git for Windows/ARM64 settled on using `clang` to compile `git.exe`, and hence needs to run in a system where `MSYSTEM` is set to `CLANGARM64` and the prefix to use is `/clangarm64`.

We already did that in the `MINGW` arm, i.e. for regular Git for Windows builds using MINGW GCC (or `clang`'s shim pretending to be GCC), now it is time to do the same in the MS Visual C part.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Just as in b64d78ad02ca (max_tree_depth: lower it for MSVC to avoid stack overflows, 2023-11-01), I encountered the same problem with the clang builds on Windows/ARM64.

The symptom is an exit code 127 when t6700 tries to verify that `git archive big` fails.

This exit code is reserved on Unix/Linux to mean "command not found". Unfortunately in this case, it is the fall-back chosen by Cygwin's `pinfo::status_exit()` method when encountering the NSTATUS `STATUS_STACK_OVERFLOW`, see https://github.com/cygwin/cygwin/blob/cygwin-3.6.1/winsup/cygwin/pinfo.cc#L171

I verified manually that the stack overflow always happens somewhere around tree depth 1403, therefore 1280 should be a safe bound in these instances.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 environment.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

On Mon, Apr 21, 2025 at 12:39:10PM +0000, Johannes Schindelin via GitGitGadget wrote:

Tiny nit, only because it puzzled me for a second: this should probably be `#elif`.

Hm. This whole construct feels rather awful, if you ask me. Instead of papering over the issue it would be nice if we eventually fixed the root cause, which is that we use recursion on a data structure that has an unbounded depth in theory.

Anyway, that is clearly outside of the scope of this patch series, so the bandaid is good enough for now.

Patrick

Hi Patrick,

On Tue, 22 Apr 2025, Patrick Steinhardt wrote:

I will change it.

True.

It is also quite awful that I cannot find a way to represent `STATUS_STACK_OVERFLOW` by anything else than exit code 127, which always misleads me into thinking that an executable or a DLL might be missing. But I did not find any.

True enough!

Thank you, Johannes

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In fb5e3378f8 (mingw: move Git for Windows' system config where users expect it, 2021-06-22), I moved the location of Git for Windows' system config and system Git attributes file to the top-level `/etc/` directory (because it is a much more obvious location than, say, `/mingw64/etc/`).

The patch relied on a very specific scenario that the newly-supported Windows/ARM64 builds of `git.exe` fails to fall into. So let's broaden the condition a bit, so that Windows/ARM64 builds also use that location (instead of the even more obscure `/clangarm64/etc/` directory).

This fixes https://github.com/git-for-windows/git/issues/5431.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Will queue.  Thanks for a cleanly structured series.

Git for Windows has started building artifacts for Windows/ARM64 since v2.47.1 (November 25th 2024). Now that Windows/ARM64 GitHub Action runners are available in public preview [https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-available-in-public-preview/] at long last, it is high time to upstream the minimal set of patches to build Git on Windows/ARM64 and pass the test suite.

Changes since v1:

 * Replaced an #else #if construct by an #elif one.

Dennis Ameling (2):
  bswap.h: add support for built-in bswap functions
  config.mak.uname: add support for clangarm64

Johannes Schindelin (4):
  mingw: do not use nedmalloc on Windows/ARM64
  msvc: do handle builds on Windows/ARM64
  mingw(arm64): do move the `/etc/git*` location
  max_tree_depth: lower it for clangarm64 on Windows

 compat/bswap.h   | 14 +++++++++++++-
 config.mak.uname | 18 ++++++++++++++----
 environment.c    | 10 ++++++++++
 3 files changed, 37 insertions(+), 5 deletions(-)

base-commit: 683c54c999c301c2cd6f715c411407c413b1d84e
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1904%2Fdscho%2Fsupport-clangarm64-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1904/dscho/support-clangarm64-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1904

Range-diff vs v1:

 1:  b89f39cbac6 = 1:  b89f39cbac6 bswap.h: add support for built-in bswap functions
 2:  2feeadb0d3f = 2:  2feeadb0d3f config.mak.uname: add support for clangarm64
 3:  6c2e17eca68 = 3:  6c2e17eca68 mingw: do not use nedmalloc on Windows/ARM64
 4:  c89ead8eaba = 4:  c89ead8eaba msvc: do handle builds on Windows/ARM64
 5:  939bcb0dc63 = 5:  939bcb0dc63 mingw(arm64): do move the `/etc/git*` location
 6:  6ebc3ef57fd ! 6:  e0e78bd5131 max_tree_depth: lower it for clangarm64 on Windows
     @@ environment.c: int max_allowed_tree_depth =
       	 * the stack overflow can occur.
       	 */
       	512;
     -+#else
     -+#if defined(GIT_WINDOWS_NATIVE) && defined(__clang__) && defined(__aarch64__)
     ++#elif defined(GIT_WINDOWS_NATIVE) && defined(__clang__) && defined(__aarch64__)
      +	/*
      +	 * Similar to Visual C, it seems that on Windows/ARM64 the clang-based
      +	 * builds have a smaller stack space available. When running out of
     @@ environment.c: int max_allowed_tree_depth =
       #else
       	2048;
       #endif
     -+#endif
     - 
     - #ifndef PROTECT_HFS_DEFAULT
     - #define PROTECT_HFS_DEFAULT 0

From: Dennis Ameling <dennis@dennisameling.com>

Newer compiler versions, like GCC 10 and Clang 12, have built-in functions for bswap32 and bswap64. This comes in handy, for example, when targeting CLANGARM64 on Windows, which would not be supported without this logic.

Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
---
 compat/bswap.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

From: Dennis Ameling <dennis@dennisameling.com>

CLANGARM64 is a relatively new MSYSTEM added by the MSYS2 team. In order to have Git build correctly for this platform, let's add some configuration for it to config.mak.uname.

Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
---
 config.mak.uname | 4 ++++
 1 file changed, 4 insertions(+)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

It does not compile there, and seeing as nedmalloc has been pretty much unmaintained since at least November 2017, as per https://github.com/ned14/nedmalloc/issues/20#issuecomment-343432314, there is also no hope that any fixes will materialize there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Notice the funny indentation above? It turns out that the one in the context that looks funnily indented uses the "correct" indentation, which is quite counter-intuitive and confusing X-<.

I forgot about the rule while reviewing the previous round, but we had to prepare for newer GNU make with commits like c18400c6 (Makefile(s): avoid recipe prefix in conditional statements, 2024-04-08). In short, the conditionals like ifn?eq, ifn?def, else, endif should not be indented with HT and we instead want them to be indented with SP.

    $ git diff master... config.mak.uname |
      grep -E -e '^[+]       +(ifn?eq|ifn?def|else|endif)'

found them in a few patches in the series that touch config.mak.uname

    msvc: do handle builds on Windows/ARM64
    mingw: do not use nedmalloc on Windows/ARM64

Fix-up for "mingw: do not use nedmalloc on Windows/ARM64"

 config.mak.uname | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Git for Windows/ARM64 settled on using `clang` to compile `git.exe`, and hence needs to run in a system where `MSYSTEM` is set to `CLANGARM64` and the prefix to use is `/clangarm64`.

We already did that in the `MINGW` arm, i.e. for regular Git for Windows builds using MINGW GCC (or `clang`'s shim pretending to be GCC), now it is time to do the same in the MS Visual C part.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In fb5e3378f8 (mingw: move Git for Windows' system config where users expect it, 2021-06-22), I moved the location of Git for Windows' system config and system Git attributes file to the top-level `/etc/` directory (because it is a much more obvious location than, say, `/mingw64/etc/`).

The patch relied on a very specific scenario that the newly-supported Windows/ARM64 builds of `git.exe` fails to fall into. So let's broaden the condition a bit, so that Windows/ARM64 builds also use that location (instead of the even more obscure `/clangarm64/etc/` directory).

This fixes https://github.com/git-for-windows/git/issues/5431.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Just as in b64d78ad02ca (max_tree_depth: lower it for MSVC to avoid stack overflows, 2023-11-01), I encountered the same problem with the clang builds on Windows/ARM64.

The symptom is an exit code 127 when t6700 tries to verify that `git archive big` fails.

This exit code is reserved on Unix/Linux to mean "command not found". Unfortunately in this case, it is the fall-back chosen by Cygwin's `pinfo::status_exit()` method when encountering the NSTATUS `STATUS_STACK_OVERFLOW`, see https://github.com/cygwin/cygwin/blob/cygwin-3.6.1/winsup/cygwin/pinfo.cc#L171

I verified manually that the stack overflow always happens somewhere around tree depth 1403, therefore 1280 should be a safe bound in these instances.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 environment.c | 10 ++++++++++
 1 file changed, 10 insertions(+)