[PATCH 0/6] Support Windows/ARM64

[PATCH 0/6] Support Windows/ARM64

[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.

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
-- 
gitgitgadget

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

[Dennis Ameling via GitGitGadget]

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(-)

diff --git a/compat/bswap.h b/compat/bswap.h
index b34054f2bd7..9e0f98e00b9 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -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)
-- 
gitgitgadget

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

[Dennis Ameling via GitGitGadget]

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(+)

diff --git a/config.mak.uname b/config.mak.uname
index b12d4e168ae..1e5d89f1aa4 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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
-- 
gitgitgadget

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

[Johannes Schindelin via GitGitGadget]

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(-)

diff --git a/config.mak.uname b/config.mak.uname
index 1e5d89f1aa4..6222d2c5a48 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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
-- 
gitgitgadget

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

[Patrick Steinhardt]

On Mon, Apr 21, 2025 at 12:39:07PM +0000, Johannes Schindelin via GitGitGadget wrote:
> 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.

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

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

[Johannes Schindelin]

Hi Patrick,

On Tue, 22 Apr 2025, Patrick Steinhardt wrote:

> On Mon, Apr 21, 2025 at 12:39:07PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > 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.
> 
> 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

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

[Johannes Schindelin via GitGitGadget]

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(-)

diff --git a/config.mak.uname b/config.mak.uname
index 6222d2c5a48..bd94f458088 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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.
 	#
-- 
gitgitgadget

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

[Johannes Schindelin via GitGitGadget]

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(-)

diff --git a/config.mak.uname b/config.mak.uname
index bd94f458088..9a95ba8c9ab 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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
-- 
gitgitgadget

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

[Johannes Schindelin via GitGitGadget]

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(+)

diff --git a/environment.c b/environment.c
index 9e4c7781be0..cc853950bb2 100644
--- a/environment.c
+++ b/environment.c
@@ -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
-- 
gitgitgadget

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

[Patrick Steinhardt]

On Mon, Apr 21, 2025 at 12:39:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/environment.c b/environment.c
> index 9e4c7781be0..cc853950bb2 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -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`.

> +	/*
> +	 * 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

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

[Johannes Schindelin]

Hi Patrick,

On Tue, 22 Apr 2025, Patrick Steinhardt wrote:

> On Mon, Apr 21, 2025 at 12:39:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > diff --git a/environment.c b/environment.c
> > index 9e4c7781be0..cc853950bb2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -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.

> > +	/*
> > +	 * 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.

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.

> 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

Re: [PATCH 0/6] Support Windows/ARM64

[Junio C Hamano]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
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(-)
>
>
> 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.

[PATCH v2 0/6] Support Windows/ARM64

[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

-- 
gitgitgadget

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

[Dennis Ameling via GitGitGadget]

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(-)

diff --git a/compat/bswap.h b/compat/bswap.h
index b34054f2bd7..9e0f98e00b9 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -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)
-- 
gitgitgadget

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

[Dennis Ameling via GitGitGadget]

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(+)

diff --git a/config.mak.uname b/config.mak.uname
index b12d4e168ae..1e5d89f1aa4 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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
-- 
gitgitgadget

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

[Johannes Schindelin via GitGitGadget]

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(-)

diff --git a/config.mak.uname b/config.mak.uname
index 1e5d89f1aa4..6222d2c5a48 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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
-- 
gitgitgadget

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

[Junio C Hamano]

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

> -	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(-)

diff --git c/config.mak.uname w/config.mak.uname
index 6222d2c5a4..3ec82d95e6 100644
--- c/config.mak.uname
+++ w/config.mak.uname
@@ -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(-)

diff --git c/config.mak.uname w/config.mak.uname
index 4831e9ccf6..4ef453ebcd 100644
--- c/config.mak.uname
+++ w/config.mak.uname
@@ -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 <johannes.schindelin@gmx.de>
    +    [jc: adjust config.mak.uname for c18400c6]
         Signed-off-by: Junio C Hamano <gitster@pobox.com>
     
      ## 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 <johannes.schindelin@gmx.de>
    +    [jc: adjust config.mak.uname for c18400c6]
         Signed-off-by: Junio C Hamano <gitster@pobox.com>
     
      ## 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

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

[Johannes Schindelin via GitGitGadget]

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(-)

diff --git a/config.mak.uname b/config.mak.uname
index 6222d2c5a48..bd94f458088 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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.
 	#
-- 
gitgitgadget

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

[Johannes Schindelin via GitGitGadget]

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(-)

diff --git a/config.mak.uname b/config.mak.uname
index bd94f458088..9a95ba8c9ab 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -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
-- 
gitgitgadget

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

[Johannes Schindelin via GitGitGadget]

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(+)

diff --git a/environment.c b/environment.c
index 9e4c7781be0..d948bb3c705 100644
--- a/environment.c
+++ b/environment.c
@@ -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
-- 
gitgitgadget