Skip to contentSkip to conversation

Support Windows/ARM64

PATCH Superseded Johannes Schindelin via GitGitGadget 4 participants 20 messages Apr 21, 2025 – Apr 23, 2025

lore
Share & tools
lore

Johannes Schindelin via GitGitGadget

author
#0 lore raw

cover Support 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

Signature · 1 line
gitgitgadget
author
#1 lore raw

PATCH 1/6 bswap.h: add support for built-in bswap functions

From: Dennis Ameling <[email protected]>

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 <[email protected]>
---
 compat/bswap.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
compat/bswap.h +13 -1
index b34054f2bd7..9e0f98e00b9 100644
@@ -35,7 +35,19 @@ static inline uint64_t default_bswap64(uint64_t val)
 #undef bswap32
 #undef bswap64
 
-#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
+/**
+ * __has_builtin is available since Clang 10 and GCC 10.
+ * Below is a fallback for older compilers.
+ */
+#ifndef __has_builtin
+	#define __has_builtin(x) 0
+#endif
+
+#if __has_builtin(__builtin_bswap32) && __has_builtin(__builtin_bswap64)
+#define bswap32(x) __builtin_bswap32((x))
+#define bswap64(x) __builtin_bswap64((x))
+
+#elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
 
 #define bswap32 git_bswap32
 static inline uint32_t git_bswap32(uint32_t x)
Signature · 1 line
gitgitgadget
author
#2 lore raw

PATCH 2/6 config.mak.uname: add support for clangarm64

In reply to Johannes Schindelin via GitGitGadget

From: Dennis Ameling <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 4 ++++
 1 file changed, 4 insertions(+)
config.mak.uname +4 -0
index b12d4e168ae..1e5d89f1aa4 100644
@@ -724,6 +724,10 @@ ifeq ($(uname_S),MINGW)
 		prefix = /mingw64
 		HOST_CPU = x86_64
 		BASIC_LDFLAGS += -Wl,--pic-executable,-e,mainCRTStartup
+        else ifeq (CLANGARM64,$(MSYSTEM))
+		prefix = /clangarm64
+		HOST_CPU = aarch64
+		BASIC_LDFLAGS += -Wl,--pic-executable,-e,mainCRTStartup
         else
 		COMPAT_CFLAGS += -D_USE_32BIT_TIME_T
 		BASIC_LDFLAGS += -Wl,--large-address-aware
Signature · 1 line
gitgitgadget
author
#3 lore raw

PATCH 3/6 mingw: do not use nedmalloc on Windows/ARM64

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
config.mak.uname +3 -1
index 1e5d89f1aa4..6222d2c5a48 100644
@@ -742,7 +742,9 @@ ifeq ($(uname_S),MINGW)
 	HAVE_LIBCHARSET_H = YesPlease
 	USE_GETTEXT_SCHEME = fallthrough
 	USE_LIBPCRE = YesPlease
-	USE_NED_ALLOCATOR = YesPlease
+	ifneq (CLANGARM64,$(MSYSTEM))
+		USE_NED_ALLOCATOR = YesPlease
+	endif
         ifeq (/mingw64,$(subst 32,64,$(prefix)))
 		# Move system config into top-level /etc/
 		ETC_GITCONFIG = ../etc/gitconfig
Signature · 1 line
gitgitgadget
#4 lore raw

Re: [PATCH 3/6] mingw: do not use nedmalloc on Windows/ARM64

Quoted 6 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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.

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

#5 lore raw

Dropping nedmalloc support? was Re: [PATCH 3/6] mingw: do not use nedmalloc on Windows/ARM64

Hi Patrick,

Quoted 10 lines · Patrick Steinhardt
Quoted 6 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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.

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?

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

author
#6 lore raw

PATCH 4/6 msvc: do handle builds on Windows/ARM64

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
config.mak.uname +5 -1
index 6222d2c5a48..bd94f458088 100644
@@ -432,7 +432,11 @@ ifeq ($(uname_S),Windows)
         ifeq (MINGW32,$(MSYSTEM))
 		prefix = /mingw32
         else
-		prefix = /mingw64
+		ifeq (CLANGARM64,$(MSYSTEM))
+			prefix = /clangarm64
+		else
+			prefix = /mingw64
+		endif
         endif
 	# Prepend MSVC 64-bit tool-chain to PATH.
 	#
Signature · 1 line
gitgitgadget
author
#7 lore raw

PATCH 5/6 mingw(arm64): do move the `/etc/git*` location

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
config.mak.uname +2 -2
index bd94f458088..9a95ba8c9ab 100644
@@ -489,7 +489,7 @@ ifeq ($(uname_S),Windows)
 	NO_POSIX_GOODIES = UnfortunatelyYes
 	NATIVE_CRLF = YesPlease
 	DEFAULT_HELP_FORMAT = html
-ifeq (/mingw64,$(subst 32,64,$(prefix)))
+ifeq (/mingw64,$(subst 32,64,$(subst clangarm,mingw,$(prefix))))
 	# Move system config into top-level /etc/
 	ETC_GITCONFIG = ../etc/gitconfig
 	ETC_GITATTRIBUTES = ../etc/gitattributes

@@ -749,7 +749,7 @@ ifeq ($(uname_S),MINGW)
 	ifneq (CLANGARM64,$(MSYSTEM))
 		USE_NED_ALLOCATOR = YesPlease
 	endif
-        ifeq (/mingw64,$(subst 32,64,$(prefix)))
+        ifeq (/mingw64,$(subst 32,64,$(subst clangarm,mingw,$(prefix))))
 		# Move system config into top-level /etc/
 		ETC_GITCONFIG = ../etc/gitconfig
 		ETC_GITATTRIBUTES = ../etc/gitattributes
Signature · 1 line
gitgitgadget
author
#8 lore raw

PATCH 6/6 max_tree_depth: lower it for clangarm64 on Windows

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 environment.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)
environment.c +12 -0
index 9e4c7781be0..cc853950bb2 100644
@@ -82,9 +82,21 @@ int max_allowed_tree_depth =
 	 * the stack overflow can occur.
 	 */
 	512;
+#else
+#if 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
+	 * that stack space, a `STATUS_STACK_OVERFLOW` is produced. When the
+	 * Git command was run from an MSYS2 Bash, this unfortunately results
+	 * in an exit code 127. Let's prevent that by lowering the maximal
+	 * tree depth; This value seems to be low enough.
+	 */
+	1280;
 #else
 	2048;
 #endif
+#endif
 
 #ifndef PROTECT_HFS_DEFAULT
 #define PROTECT_HFS_DEFAULT 0
Signature · 1 line
gitgitgadget
#9 lore raw

Re: [PATCH 6/6] max_tree_depth: lower it for clangarm64 on Windows

environment.c int max_allowed_tree_depth = · line 86

Quoted 10 lines · Johannes Schindelin via GitGitGadget
environment.c +2 -0
index 9e4c7781be0..cc853950bb2 100644
@@ -82,9 +82,21 @@ int max_allowed_tree_depth =
 	 * the stack overflow can occur.
 	 */
 	512;
+#else
+#if defined(GIT_WINDOWS_NATIVE) && defined(__clang__) && defined(__aarch64__)

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

environment.c int max_allowed_tree_depth = · line 99

Quoted 13 lines
environment.c +10 -0
+	/*
+	 * Similar to Visual C, it seems that on Windows/ARM64 the clang-based
+	 * builds have a smaller stack space available. When running out of
+	 * that stack space, a `STATUS_STACK_OVERFLOW` is produced. When the
+	 * Git command was run from an MSYS2 Bash, this unfortunately results
+	 * in an exit code 127. Let's prevent that by lowering the maximal
+	 * tree depth; This value seems to be low enough.
+	 */
+	1280;
 #else
 	2048;
 #endif
+#endif

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

#10 lore raw

Re: [PATCH 6/6] max_tree_depth: lower it for clangarm64 on Windows

Hi Patrick,

Quoted 14 lines · Patrick Steinhardt

environment.c int max_allowed_tree_depth = · line 86

Quoted 10 lines · Johannes Schindelin via GitGitGadget
environment.c +2 -0
index 9e4c7781be0..cc853950bb2 100644
@@ -82,9 +82,21 @@ int max_allowed_tree_depth =
 	 * the stack overflow can occur.
 	 */
 	512;
+#else
+#if defined(GIT_WINDOWS_NATIVE) && defined(__clang__) && defined(__aarch64__)

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

I will change it.

Quoted 10 lines
Quoted 10 lines
environment.c +9 -0
+	/*
+	 * Similar to Visual C, it seems that on Windows/ARM64 the clang-based
+	 * builds have a smaller stack space available. When running out of
+	 * that stack space, a `STATUS_STACK_OVERFLOW` is produced. When the
+	 * Git command was run from an MSYS2 Bash, this unfortunately results
+	 * in an exit code 127. Let's prevent that by lowering the maximal
+	 * tree depth; This value seems to be low enough.
+	 */
+	1280;
 #else
Quoted 8 lines

environment.c int max_allowed_tree_depth = · line 99

Quoted 3 lines
environment.c +1 -0
 	2048;
 #endif
+#endif

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.

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.

Quoted 2 lines

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

True enough!

Thank you,
Johannes

#11 lore raw
In reply to Johannes Schindelin via GitGitGadget

"Johannes Schindelin via GitGitGadget" <[email protected]>

Quoted 23 lines · writes:

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(-)
Quoted 4 lines

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

Will queue. Thanks for a cleanly structured series.

author
#12 lore raw

v2 cover Support Windows/ARM64

In reply to Johannes Schindelin via GitGitGadget

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
Signature · 1 line
gitgitgadget
author
#13 lore raw

PATCH v2 1/6 bswap.h: add support for built-in bswap functions

From: Dennis Ameling <[email protected]>

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 <[email protected]>
---
 compat/bswap.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
compat/bswap.h +13 -1
index b34054f2bd7..9e0f98e00b9 100644
@@ -35,7 +35,19 @@ static inline uint64_t default_bswap64(uint64_t val)
 #undef bswap32
 #undef bswap64
 
-#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
+/**
+ * __has_builtin is available since Clang 10 and GCC 10.
+ * Below is a fallback for older compilers.
+ */
+#ifndef __has_builtin
+	#define __has_builtin(x) 0
+#endif
+
+#if __has_builtin(__builtin_bswap32) && __has_builtin(__builtin_bswap64)
+#define bswap32(x) __builtin_bswap32((x))
+#define bswap64(x) __builtin_bswap64((x))
+
+#elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
 
 #define bswap32 git_bswap32
 static inline uint32_t git_bswap32(uint32_t x)
Signature · 1 line
gitgitgadget
author
#14 lore raw

PATCH v2 2/6 config.mak.uname: add support for clangarm64

In reply to Johannes Schindelin via GitGitGadget

From: Dennis Ameling <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 4 ++++
 1 file changed, 4 insertions(+)
config.mak.uname +4 -0
index b12d4e168ae..1e5d89f1aa4 100644
@@ -724,6 +724,10 @@ ifeq ($(uname_S),MINGW)
 		prefix = /mingw64
 		HOST_CPU = x86_64
 		BASIC_LDFLAGS += -Wl,--pic-executable,-e,mainCRTStartup
+        else ifeq (CLANGARM64,$(MSYSTEM))
+		prefix = /clangarm64
+		HOST_CPU = aarch64
+		BASIC_LDFLAGS += -Wl,--pic-executable,-e,mainCRTStartup
         else
 		COMPAT_CFLAGS += -D_USE_32BIT_TIME_T
 		BASIC_LDFLAGS += -Wl,--large-address-aware
Signature · 1 line
gitgitgadget
author
#15 lore raw

PATCH v2 3/6 mingw: do not use nedmalloc on Windows/ARM64

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
config.mak.uname +3 -1
index 1e5d89f1aa4..6222d2c5a48 100644
@@ -742,7 +742,9 @@ ifeq ($(uname_S),MINGW)
 	HAVE_LIBCHARSET_H = YesPlease
 	USE_GETTEXT_SCHEME = fallthrough
 	USE_LIBPCRE = YesPlease
-	USE_NED_ALLOCATOR = YesPlease
+	ifneq (CLANGARM64,$(MSYSTEM))
+		USE_NED_ALLOCATOR = YesPlease
+	endif
         ifeq (/mingw64,$(subst 32,64,$(prefix)))
 		# Move system config into top-level /etc/
 		ETC_GITCONFIG = ../etc/gitconfig
Signature · 1 line
gitgitgadget
#16 lore raw

Re: [PATCH v2 3/6] mingw: do not use nedmalloc on Windows/ARM64

"Johannes Schindelin via GitGitGadget" <[email protected]>

Review

Quoted 5 lines · writes:
(quoted diff) +3 -1
-	USE_NED_ALLOCATOR = YesPlease
+	ifneq (CLANGARM64,$(MSYSTEM))
+		USE_NED_ALLOCATOR = YesPlease
+	endif
         ifeq (/mingw64,$(subst 32,64,$(prefix)))

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(-)
config.mak.uname +2 -2
index 6222d2c5a4..3ec82d95e6 100644
@@ -742,9 +742,9 @@ ifeq ($(uname_S),MINGW)
 	HAVE_LIBCHARSET_H = YesPlease
 	USE_GETTEXT_SCHEME = fallthrough
 	USE_LIBPCRE = YesPlease
-	ifneq (CLANGARM64,$(MSYSTEM))
+        ifneq (CLANGARM64,$(MSYSTEM))
 		USE_NED_ALLOCATOR = YesPlease
-	endif
+        endif
         ifeq (/mingw64,$(subst 32,64,$(prefix)))
 		# Move system config into top-level /etc/
 		ETC_GITCONFIG = ../etc/gitconfig

Fix-up for "msvc: do handle builds on Windows/ARM64"

 config.mak.uname | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
config.mak.uname +3 -3
index 4831e9ccf6..4ef453ebcd 100644
@@ -432,11 +432,11 @@ ifeq ($(uname_S),Windows)
         ifeq (MINGW32,$(MSYSTEM))
 		prefix = /mingw32
         else
-		ifeq (CLANGARM64,$(MSYSTEM))
+                ifeq (CLANGARM64,$(MSYSTEM))
 			prefix = /clangarm64
-		else
+                else
 			prefix = /mingw64
-		endif
+                endif
         endif
 	# Prepend MSVC 64-bit tool-chain to PATH.
 	#

Taken as a whole, here is a range-diff of what I will queue based on this iteration.

Thanks.

1: da1408a34e ! 1: 734bf24007 mingw: do not use nedmalloc on Windows/ARM64
@@ Commit message
there is also no hope that any fixes will materialize there.

Signed-off-by Johannes Schindelin <[email protected]>

+ [jc: adjust config.mak.uname for c18400c6]

Signed-off-by Junio C Hamano <[email protected]>

## config.mak.uname ##
@@ config.mak.uname: ifeq ($(uname_S),MINGW)
USE_GETTEXT_SCHEME = fallthrough
USE_LIBPCRE = YesPlease
- USE_NED_ALLOCATOR = YesPlease
-+ ifneq (CLANGARM64,$(MSYSTEM))
++ ifneq (CLANGARM64,$(MSYSTEM))
+ USE_NED_ALLOCATOR = YesPlease
-+ endif
++ endif
ifeq (/mingw64,$(subst 32,64,$(prefix)))
# Move system config into top-level /etc/ ETC_GITCONFIG = ../etc/gitconfig
2: e27caa3dca ! 2: 8945fba590 msvc: do handle builds on Windows/ARM64

    @@ Commit message
         is time to do the same in the MS Visual C part.
     
         Signed-off-by: Johannes Schindelin <[email protected]>
    +    [jc: adjust config.mak.uname for c18400c6]
         Signed-off-by: Junio C Hamano <[email protected]>
     
      ## config.mak.uname ##
    @@ config.mak.uname: ifeq ($(uname_S),Windows)
      		prefix = /mingw32
              else
     -		prefix = /mingw64
    -+		ifeq (CLANGARM64,$(MSYSTEM))
    ++                ifeq (CLANGARM64,$(MSYSTEM))
     +			prefix = /clangarm64
    -+		else
    ++                else
     +			prefix = /mingw64
    -+		endif
    ++                endif
              endif
      	# Prepend MSVC 64-bit tool-chain to PATH.
      	#

3: f1f6c1f2fa ! 3: 619950d421 mingw(arm64): do move the /etc/git* location
@@ config.mak.uname: ifeq ($(uname_S),Windows)
ETC_GITCONFIG = ../etc/gitconfig
ETC_GITATTRIBUTES = ../etc/gitattributes
@@ config.mak.uname: ifeq ($(uname_S),MINGW)
- ifneq (CLANGARM64,$(MSYSTEM))
+ ifneq (CLANGARM64,$(MSYSTEM))
USE_NED_ALLOCATOR = YesPlease
- endif
+ endif
- ifeq (/mingw64,$(subst 32,64,$(prefix)))
+ ifeq (/mingw64,$(subst 32,64,$(subst clangarm,mingw,$(prefix))))
# Move system config into top-level /etc/
4: 687bd4ea96 = 4: 436a42215e max_tree_depth: lower it for clangarm64 on Windows

author
#17 lore raw

PATCH v2 4/6 msvc: do handle builds on Windows/ARM64

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
config.mak.uname +5 -1
index 6222d2c5a48..bd94f458088 100644
@@ -432,7 +432,11 @@ ifeq ($(uname_S),Windows)
         ifeq (MINGW32,$(MSYSTEM))
 		prefix = /mingw32
         else
-		prefix = /mingw64
+		ifeq (CLANGARM64,$(MSYSTEM))
+			prefix = /clangarm64
+		else
+			prefix = /mingw64
+		endif
         endif
 	# Prepend MSVC 64-bit tool-chain to PATH.
 	#
Signature · 1 line
gitgitgadget
author
#18 lore raw

PATCH v2 5/6 mingw(arm64): do move the `/etc/git*` location

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 config.mak.uname | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
config.mak.uname +2 -2
index bd94f458088..9a95ba8c9ab 100644
@@ -489,7 +489,7 @@ ifeq ($(uname_S),Windows)
 	NO_POSIX_GOODIES = UnfortunatelyYes
 	NATIVE_CRLF = YesPlease
 	DEFAULT_HELP_FORMAT = html
-ifeq (/mingw64,$(subst 32,64,$(prefix)))
+ifeq (/mingw64,$(subst 32,64,$(subst clangarm,mingw,$(prefix))))
 	# Move system config into top-level /etc/
 	ETC_GITCONFIG = ../etc/gitconfig
 	ETC_GITATTRIBUTES = ../etc/gitattributes

@@ -749,7 +749,7 @@ ifeq ($(uname_S),MINGW)
 	ifneq (CLANGARM64,$(MSYSTEM))
 		USE_NED_ALLOCATOR = YesPlease
 	endif
-        ifeq (/mingw64,$(subst 32,64,$(prefix)))
+        ifeq (/mingw64,$(subst 32,64,$(subst clangarm,mingw,$(prefix))))
 		# Move system config into top-level /etc/
 		ETC_GITCONFIG = ../etc/gitconfig
 		ETC_GITATTRIBUTES = ../etc/gitattributes
Signature · 1 line
gitgitgadget
author
#19 lore raw

PATCH v2 6/6 max_tree_depth: lower it for clangarm64 on Windows

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>
---
 environment.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
environment.c +10 -0
index 9e4c7781be0..d948bb3c705 100644
@@ -82,6 +82,16 @@ int max_allowed_tree_depth =
 	 * the stack overflow can occur.
 	 */
 	512;
+#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
+	 * that stack space, a `STATUS_STACK_OVERFLOW` is produced. When the
+	 * Git command was run from an MSYS2 Bash, this unfortunately results
+	 * in an exit code 127. Let's prevent that by lowering the maximal
+	 * tree depth; This value seems to be low enough.
+	 */
+	1280;
 #else
 	2048;
 #endif
Signature · 1 line
gitgitgadget