Conversation
Add winsup/cygwin/aarch64/fastcwd.cc, the AArch64 counterpart to the x86_64 fast current-working-directory probing used by path_conv. (cherry picked from commit 61007db)
|
|
||
| extern void *malloc (size_t); | ||
| #ifdef __CYGWIN__ | ||
| #if defined(__CYGWIN__) || defined(__MSYS__) |
There was a problem hiding this comment.
It's a bit curious that this is needed for ARM64, but not for x64?
There was a problem hiding this comment.
Right — it's only needed because our aarch64 build defines MSYS (triple aarch64-pc-msys); x64 builds as *-pc-cygwin so CYGWIN already covers it. Once we retarget the toolchain to aarch64-pc-cygwin, this change isn't needed and we'll drop it.
| # Don't use for these since they provide their own setjmp. | ||
| case ${host} in | ||
| *-*-sco* | *-*-cygwin*) | ||
| *-*-sco* | *-*-cygwin* | *-*-msys*) |
There was a problem hiding this comment.
This seems to revert #303. Would you be able to adjust the aarch64-* toolchain to recapitulate the change from x86_64-pc-msys to x86_64-pc-cygwin?
There was a problem hiding this comment.
Agreed — this was unintentionally reverting #303 (we'd missed that it had landed). We'll recapitulate the x86_64-pc-msys → x86_64-pc-cygwin change for aarch64-* instead of re-adding --msys*, so this hunk goes away.
Thanks for catching this! You're right — #303 was merged fairly recently and we hadn't noticed it, so we didn't realize these changes were re-introducing the --msys* triple that #303 had deliberately removed. That explains the MSYS/--msys* bits — they only exist because our aarch64 toolchain still targets aarch64-pc-msys, whereas x64 now builds as *-pc-cygwin. We'll retarget our aarch64 toolchain to aarch64-pc-cygwin (mirroring the x86_64-pc-msys → x86_64-pc-cygwin change) and then drop both the --msys* change in configure.host/configure.ac and the MSYS guard in malloc.h. The remaining aarch64 runtime commits (fast_cwd, uname, exit_process, getprocaddrarm64) stand on their own. I'll push the updated series once the toolchain is rebuilt. |
uname() and uname_x() returned "unknown" as the machine name on ARM64 Windows. Map PROCESSOR_ARCHITECTURE_ARM64 to "aarch64". (cherry picked from commit 5bc1d33)
getprocaddrarm64.exe is now provided, so the "provide exes for these" TODO only applies to the 32-bit ARM (ARMNT) helper. Reword the comment accordingly. (cherry picked from commit 345e368)
…sent Native ARM64 (PID_NOTCYGWIN) processes should be terminated gently via a console helper instead of TerminateProcess. Probe for aarch64-w64-mingw32-gcc in winsup/configure.ac and build getprocaddrarm64 under the HAVE_MINGWARM64_CC conditional. The probe is done unconditionally (outside the with_cross_bootstrap / mingw-progs block) and never errors when the compiler is absent, so the helper builds on Windows-on-ARM cross setups (e.g. --with-cross-bootstrap) without requiring the x86 MinGW compilers, and x86 hosts are unaffected. Note: winsup/configure is generated; run autoreconf so the new AC_CHECK_PROGS/AM_CONDITIONAL take effect. Co-authored-by: chandru-mcw <chandru.kumaresan@multicorewareinc.com> (cherry picked from commit 4b38982)
This patch adds configure options allowing to disable build of cygserver and Cygwin utilities. This is useful when one needs to build only cygwin1.dll and crt0.o with stage1 compiler that is not yet capable of linking executables as it is missing cygwin1.dll and crt0.o. Signed-off-by: Radek Bartoň <radek.barton@microsoft.com>
The ARM64 runtime shipped zero winsup utils because it configures
--disable-utils --without-mingw-progs --with-cross-bootstrap, which skips the
entire utils/ tree (including the utils/mingw/ MinGW host tools). This adds a
scoped opt-in so the cross build produces the MinGW host tools through automake,
exactly as the native x86_64 build does -- no hand-written compile line -- while
the ~26 cygwin-linked utils in utils/ stay deferred.
winsup/configure.ac:
- new --enable-mingw-utils (default off) => AM_CONDITIONAL(BUILD_MINGW_UTILS)
- enter the MinGW probe block when --enable-mingw-utils is given even under
--without-mingw-progs, so @MINGW_CXX@ resolves (the PKGBUILD overrides it to
aarch64-w64-mingw32-g++)
- the i686/x86_64 MinGW compilers become optional under the opt-in (they are
absent on the ARM64 box); add HAVE_MINGW32_CC / HAVE_MINGW64_CC, mirroring
the existing HAVE_MINGWARM64_CC
winsup/Makefile.am: enter utils/ under BUILD_MINGW_UTILS as well as BUILD_UTILS.
winsup/utils/Makefile.am: build the cygwin-linked bin_PROGRAMS only under
BUILD_UTILS (unchanged for x86_64); descend into mingw/ under CROSS_BOOTSTRAP
or BUILD_MINGW_UTILS.
winsup/utils/mingw/Makefile.am: in mingw-utils-only mode build just
cygwin-console-helper and ldh; build getprocaddr32/64/arm64 each only when its
compiler is present.
Default off => a strict no-op for every existing configuration.
strace.exe segfaults on aarch64-pc-msys when tracing a process (issue #20). The only signal today is the shell's bare "Segmentation fault" line; the fault reproduces only on the ARM64 box, so root-causing it needs a fault address we currently don't have. Install a vectored exception handler plus a last-resort unhandled-filter in main2() that, on a genuine fault, print the exception code, the faulting instruction address, and -- decisively -- the module + offset that address resolves to (via GetModuleHandleExW FROM_ADDRESS), so we can tell immediately whether the PC is in strace.exe's own logic or inside msys-2.0.dll. A few registers are dumped from the CONTEXT record (ARM64 and x86_64 branches). GCC-SEH pseudo-exceptions, breakpoints and the SetThreadName marker are skipped so only real crashes are reported; the trace file is flushed first so no captured lines are lost. Inert unless a fault occurs, pure win32/ntdll (no cygwin runtime dependency), so it is safe in this -lntdll util and stays permanently. Compile-checked for both aarch64-w64-mingw32 and x86_64 with -Wall -Wextra.
87b5d73 to
a6e58e7
Compare
quoted() deletes an in-place quote with strcpy (cmd, cmd + 1), where source and destination overlap. That is undefined, and only works by accident on implementations that copy a byte at a time. The AArch64 SIMD strcpy rounds the source pointer down to a 16-byte boundary and loads that entire block, so storing it back one byte lower duplicates bytes inside the block while keeping the string length. Command lines from a native parent such as cmd.exe therefore arrived mangled, with the damage depending on where the string happened to sit in memory. Use memmove, which is defined for overlapping buffers, in both places.
aswin-mcw
changed the title
a6e58e7 to
93905e8
Compare
|
@dscho The retarget to |
|
@aswin-mcw this is great! I am currently quite busy preparing for a new Git for Windows release, which is complicated by the fact that we have to migrate away from MINGW64. So I cannot have a look at this right now. But I'm really excited about this and hope to be able to assist soon! |
5 participants
Summary
Adds the msys2-runtime pieces needed to build and run the runtime on AArch64
(Windows on ARM64), targeting
aarch64-pc-cygwin. All new build steps aregated behind compiler probes or arch conditionals, so x86/x86_64 are unaffected.
Changes
Build / configury
aarch64-w64-mingw32-gcc, build under a newHAVE_MINGWARM64_CC. Never errors when absent.--disable-cygserver/--disable-utilsfor stage-1 bootstrap. Both default to enabled.--enable-mingw-utilsbuilds only theutils/mingwhost tools. Defaults off.Runtime (winsup/cygwin)
winsup/cygwin/aarch64/fastcwd.cc."aarch64"forPROCESSOR_ARCHITECTURE_ARM64(was"unknown").strcpy (cmd, cmd + 1)overlaps;AArch64's SIMD
strcpyduplicates bytes and mangles command lines from anative parent such as
cmd.exe. Usememmove.Diagnostics
The aarch64-pc-cygwin toolchain
Built and validated with a full cross toolchain targeting
aarch64-pc-cygwin,built on an
x86_64-pc-msyshost and installable via pacman: binutils, atwo-stage GCC (C, C++, libstdc++, libgomp, libatomic, libquadmath), and the
MSYS2 runtime itself (
msys-2.0.dll), bootstrapped with stage-1 GCC andrebuilt with stage-2.
AArch64 support in Cygwin/newlib this builds on
MSYS2-runtime is a friendly fork of Cygwin and rebases onto upstream Cygwin
releases, so the bulk of the AArch64 enablement lives in Cygwin/newlib
itself. The changes in this PR only build and run on top of that work — they
are not usable without it.
That AArch64 port has been a sustained effort since early 2025 (first
patches landed in March 2025), and a large share of the commits below were
authored by our team, with several still under review. The remainder is other
upstream AArch64 work we build on. Full per-commit authorship is in the Git
history.
Merged upstream
64 commits (click to expand)
Under review (cygwin-patches)
Notes for reviewers
msys2-3.6.10.winsup/configureis not yet regenerated in this PR; theconfigure.acchange needs
autoreconfto take effect. I can add the regeneratedconfigureif you would prefer it in-tree.