Add native support for Windows on Arm64 (WoA)

[chirontt]

• add a new fragment org.eclipse.cdt.core.win32.aarch64 containing re-compiled Arm64 natives suitable for the WoA platform.
• add the serial.dll binary re-compiled for WoA.
• add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment.

This PR would fix issue #969.

To build the various CDT natives for the WoA platform, a WoA box (or VM) is needed and the MSYS2 for ARM64 is installed on that WoA box to provide a unixy environment for the native build steps below.

Installing MSYS2 for ARM64

Follow the MSYS2 for ARM64 instructions to install the MSYS2 environment on the WoA box. Note that the clangarm64.exe shell must be used to provide ARM64 environment/tools for subsequent build steps.

The clangarm64 shell will output the following string for the uname command:

$ uname
MINGW64_NT-10.0-22631-ARM64

This uname output string will be used in various Makefile's to detect the WoA runtime environment when building binaries for it.

In the clangarm64 shell, install the needed LLVM-based MingGW64 compiler for ARM64:

$ pacman -S mingw-w64-clang-aarch64-clang

The above mingw-w64-clang-aarch64-clang package provides a complete MingGW64 toolchain for ARM64, including the GNU make utility available in the form of the mingw32-make command, which can be alias'ed as make for ease of use if needed:

$ alias make="mingw32-make"

With the above mingw-w64-clang-aarch64-clang package installed, the following compiler commands are all equivalent and are all pointing to the same LLVM Clang compiler for ARM64: gcc, cc, clang, aarch64-w64-mingw32-gcc, etc.

$ gcc --version
clang version 19.1.4
Target: aarch64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/clangarm64/bin

Also install any needed utilities, such as python (needed by various Makefile's later):

$ pacman -S python3

Building winpty.dll and winpty-agent.exe binaries for WoA

There are no winpty source code in the CDT repo, apart from the header file winpty.h.

Re-compiling these binaries for WoA will need to fetch the official winpty repo source code, especially the 0.3.1 version tag which is compatible with our current pty.cpp source code. But even this 0.3.1 version tag source still doesn't support compiling it for WoA, so I've forked it and added some changes to its configure file to support compiling it in the MSYS2 environment for WoA, in my 0.3.1_arm64 branch of the fork.

And thus, to compile winpty binaries for WoA, we just follow the official build instructions: ./configure then make commands. Here are the complete commands to build it from my fork, running in the MSYS2 clangarm64 shell:

$ git clone -b 0.3.1_arm64 https://github.com/chirontt/winpty
$ cd winpty && ./configure && make

The above make command will eventually fail to compile the Unix adapter winpty.exe, as it requires the CYGWIN environment which doesn't exist in WoA, and can be ignored. But the needed winpty.dll and winpty-agent.exe files would be successfully produced in the build subdirectory (and then be manually copied over to the cdt/core/org.eclipse.cdt.core.win32.aarch64/os/win32/aarch64 folder.)

Building pty.dll, spawner.dll and starter.exe binaries for WoA

With the above dependency winpty.dll binary for WoA available in the core/org.eclipse.cdt.core.win32.aarch64/os/win32/aarch64 folder, it's now possible to compile the pty.dll, spawner.dll and starter.exe binaries for WoA, by executing the following commands in the MSYS2 clangarm64 shell:

$ cd core/org.eclipse.cdt.core.native/native_src
$ make

and the pty.dll, spawner.dll and starter.exe binaries for WoA would be successfully produced in the core/org.eclipse.cdt.core.win32.aarch64/os/win32/aarch64 folder.

Building serial.dll binary for WoA

Similarly, the serial.dll binary for WoA can be built with the following commands executing in the MSYS2 clangarm64 shell:

$ cd native/org.eclipse.cdt.native.serial/native_src
$ make

and the serial.dll binary for WoA would be successfully produced in the native/org.eclipse.cdt.native.serial/os/win32/aarch folder.

[jonahgraham]

@chirontt this looks great on a first pass. I need to figure out where I can build/reproduce the build, but that is the only blocking issue.

There are no winpty source code in the CDT repo, apart from the header file winpty.h.

Rather than trying to do this, we should just not support winpty on WoA. I assume any WoA version of Windows has support for ConPTY. CDT's legacy use of winpty only exists as a fallback for older Windows versions.

Note that ConPTY does not have a native part, and instead uses JNA to access the DLL. (Source link)

[chirontt]

How much impact/effort needed to change the existing Java code to use this ConPTY class? Who will do this work? (not me for sure, as I'm unfamiliar with these code.)

If we can remove the need for the winpty binaries, then it will simplify things a lot:

• removal of winpty.dll, winpty-agent.exe, pty.dll
• what remains to be re-compiled will be spawner.dll and starter.exe. Don't know what starter.exe does, but the spawner.dll binary seems redundant
• even if the above spawner.dll and starter.exe need be re-compiled for WoA, the work can be done by cross-compiling from a Linux box, fitting with the existing CI/CD infrastructure. What's needed for the cross-compile to WoA is to use the llvm-mingw compiler temporarily for now (and for WoA only), while waiting for GCC 15 to become available next year
• and there won't be any need for a WoA box to do tons of manual stuff mentioned in the description above.

[jonahgraham]

How much impact/effort needed to change the existing Java code to use this ConPTY class? Who will do this work? (not me for sure, as I'm unfamiliar with these code.)

I have already done the work to ConPTY - it is used by default and in preference to winpty when running on a version of Windows that supports it. What I don't have access to test is that it works as expected on WoA machine.

[jonahgraham]

To test if ConPTY is working, create a new terminal to the local console (cmd.exe for example). Hopefully it "just works". If PTY.java fails to load ConPTY it should log an error starting with "Failed start a new style ConPTY" and then it will fallback to winpty.

[jonahgraham]

Don't know what starter.exe does

This handles group level signals so that process trees can be killed and otherwise signaled. IIRC this has to be a separate process and it exists to ensure things like terminate in CDT debug actually kills all processes. Without starter, you end up with processes still running. The comments in Spawner.java explain this a little. The starter.exe is launched from the spawner.dll (from here in Java)

but the spawner.dll binary seems redundant

Not sure why it is redundant? What is possible is to refactor spawner.dll to use JNA (like ConPTY did) so that we don't need native compiled for that part.

use the llvm-mingw compiler temporarily for now

If I update the Dockerfiles to include this, and add it to a build, can you test the resulting dlls/exes work as expected?

[chirontt]

ConPTY - it is used by default and in preference to winpty

Instead of writing some unit code to test ConPTY, I'm playing around with these ConPTY/winpty things using the Terminal view (from Eclipse IDE menu: Window -> Show View -> Terminal, then select a Local Terminal to launch:

)
and I'm discovering that your assertion above isn't quite correct. It seems winpty is always used i.e. ConPTY is always disabled in Windows, in both x64 and WoA boxes.

Browsing the PTY.java source, here's the culprit in its static block to back my claim:

cdt/core/org.eclipse.cdt.core.native/src/org/eclipse/cdt/utils/pty/PTY.java

Lines 295 to 300 in 7a237aa

	// Force conpty off by default
	// NOTE: to invert the default, the presence of the property must be checked too, not
	// just the getBoolean return!
	if (!Boolean.getBoolean("org.eclipse.cdt.core.conpty_enabled")) { //$NON-NLS-1$
	isConPTY = IS_CONPTY.CONPTY_NO;
	}

That block of code always disables the ConPTY, unless the org.eclipse.cdt.core.conpty_enabled system property is true. This property is not set at all by default in the Eclipse IDE, so the ConPTY is disabled by default, and winpty is used instead in Windows.

Some other troubling code in the same static block:

cdt/core/org.eclipse.cdt.core.native/src/org/eclipse/cdt/utils/pty/PTY.java

Lines 302 to 310 in 7a237aa

	isWinPTY = isWindows;
	if (isWindows) {
	// When we used to build with VC++ we used DelayLoadDLLs (See Gerrit 167674 and Bug 521515) so that the winpty
	// could be found. When we ported to mingw we didn't port across this feature because it was simpler to just
	// manually load winpty first.
	System.loadLibrary("winpty"); //$NON-NLS-1$
	}
	System.loadLibrary("pty"); //$NON-NLS-1$
	hasPTY = true;

Line 302 sets the isWinPTY flag to true just because it's Windows (???). And because it's Windows, the winpty.dll library is also always loaded in line 307; same as the pty.dll library in line 309. All these behaviours need be changed if/when we want to throw out those libraries and replace them with the JNA-based ConPTY class.

One consolation is that, on my WoA box, when I add the following property to the eclipse.ini file:

-Dorg.eclipse.cdt.core.conpty_enabled=true

and also remove all the winpty binaries from the Eclipse IDE (to force the use of the ConPTY class with no other choice), the Terminal view works fine, showing the cmd.exe program working in its view. So my conclusion is that ConPTY is available and working in WoA.

[chirontt]

If I update the Dockerfiles to include this, and add it to a build, can you test the resulting dlls/exes work as expected?

Yes, I'll use my WoA box for testing these WoA-related stuff.

[jonahgraham]

That block of code always disables the ConPTY, unless the org.eclipse.cdt.core.conpty_enabled system property is true.

The code you quoted is a fairly old version of the code (at least before 4c87198 - looks like CDT 10.5 branch)- the default in current main branch is enabled with this bit of code:

cdt/core/org.eclipse.cdt.core.native/src/org/eclipse/cdt/utils/pty/PTY.java

Lines 295 to 300 in a24f93d

	// Disable ConPTY if the user needs to
	boolean conPtyEnabled = Boolean
	.parseBoolean(System.getProperty("org.eclipse.cdt.core.conpty_enabled", "true")); //$NON-NLS-1$ //$NON-NLS-2$
	if (!conPtyEnabled) {
	isConPTY = IS_CONPTY.CONPTY_NO;
	}

And because it's Windows, the winpty.dll library is also always loaded in line 307

This is still true on latest version - and we should fix that so winpty failing to load is not a catastrophic failure like it is now.

I would consider removing winpty on x86_64 too, but everytime I remove support for an ancient feature people chime in how they are affected.

[jonahgraham]

and we should fix that so winpty failing to load is not a catastrophic failure like it is now.

I am working on this part

[jonahgraham]

I have made some good progress on refactoring the code to not require winpty, as well as updating docker images. My WIP code is https://github.com/jonahgraham/cdt/tree/woa - but I am done for today.

[jonahgraham]

@chirontt I made some small changes to your commit and changed the target branch to eclipse-cdt:support_windows_on_arm64

Changes made:

• Removed all compiled code - that will be added back in subsequent commits based on the Docker builds
• Code cleanup

I am going to merge this now to the support_windows_on_arm64 branch and then add my commits which add the docker build support. That will lead to a testable p2 repo.