Windows arm64 support

[Tres Finocchiaro]

Hi, I'm interested in using JNA with Microsoft's Early Access Java 15 version for Windows on arm64: https://github.com/microsoft/openjdk-aarch64/releases

However, I'm slightly concerned about this part of the Windows JNA build tutorial:

> On 64-bit windows, you will still need to install mingw64 in order to compile a small bit of inline assembly.

Is this "inline assembly" going to cause build issues with ARM?  Last I checked, mingw didn't have a Windows ARM version unless it's built with Clang however since the tutorial references Cygwin, I assume it's built with gcc, no?

If the user's list isn't a good place to have this discussion, I'd be happy to work from a dedicated bug report, but I don't want to clutter the tracker.

Best of regards,

-Tres

[Daniel B. Widdis]

I'm certainly not the expert here, but I did just review the source for the instances of __asm__.  Most are in the libffi sources, which has an arm branch so I'd hope they are fine.

The other 3 instances are in protect.h in a block that does not look executed on Win64 

#ifdef _WIN64

#error "GCC does not implement SEH"

#else

#define SEH_TRY(ER) \

  __asm__ ("movl %%fs:0, %0" : "=r" ((ER).ex_reg.prev));  \

  __asm__ ("movl %0, %%fs:0" : : "r" (&(ER)))

#define SEH_CATCH(ER) \

  __asm__ ("movl %0, %%fs:0" : : "r" ((ER).ex_reg.prev))

#endif /* !_WIN64 */

Interpreting what that means requires more knowledge than I have, but it looks hopeful to me in a situation someone thought of and handled.

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/64abd6b4-d398-4ee6-9f21-943929bfcf84o%40googlegroups.com.

--

Dan Widdis

[Tres Finocchiaro]

Dan,

Thanks kindly for your review.  Are you stating that the assembly code should be compilable without gcc?  If so, I'm happy to start working from the tutorial/propose changes as I see them.

[Tres Finocchiaro]

... also, I'd like to add that this "build with ARM" is a bit of a misnomer.  Last I checked, Microsoft's tools are still 32-bit Intel even on ARM, so it's more of a cross-compiling nature.  I'm just not sure how the assembly fits in since it references tools that I think I can safely assume will provide instruction sets for the wrong architecture.  I'm just not sure where these tools reside and if they're critical to the architecture of the end-binaries or that of the build toolchain, etc (I'm also a Java developer by trade, so my Clang/GCC/MSVC experience is limited).

[Daniel B. Widdis]

I don't know the answer for sure. 

But what I am trying to say is that I think the native builds using gcc will probably not need to access any assembly.  But that is purely from looking at the source code.  I would be hopeful.  You can always try it!

On Wed, Jul 15, 2020 at 1:21 PM Tres Finocchiaro <tres.fin...@gmail.com> wrote:

Dan,

Thanks kindly for your review.  Are you stating that the assembly code should be compilable without gcc?  If so, I'm happy to start working from the tutorial/propose changes as I see them.

--

You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/CANQs7dA0WB8_M2uuhaUU-G4zdU7Z--WknXPY8jcnVMJBDZjitA%40mail.gmail.com.

--

Dan Widdis

[Tres Finocchiaro]

I've gotten a bit further but still hitting quite a few snags... 

I believe to configure MSVC for ARM binaries, the environment must be set with:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat" -arch=arm64 -host_arch=x86

Since the build system is automake, it uses many posix tools, requiring cygwin.  The x86 version of cygwin seems to work quite well, but the build instructions seem to vary between using cygwin to build and using CMD.

Using cygwin is a bit tricky, since it requires exports that point to several build directories.

Using cmd seems to be a bit easier, since it can simply add cygwin's bin folder to PATH and make tools accessible.  Whether or not this pollutes the paths, I'm not certain (e.g. C:\foo versus /cygdrive/c/foo).

So I assume the goal is to inform automake to use cl.exe to build using arm64.  At a glance, it's assuming x86, which I believe to be my first problem.

Reading the Makefile, it's relying on Cygwin's value of $ARCH, which resolves to "i686", later translated to "i386" when using the 32-bit Cygwin version.  Naturally, this is incorrect since the target is arm64/aarch64 however forcing this value doesn't seem to help and it specifically says it's overridden by ant.

I'm still a bit unsure whether or not stuff like libtool is going to be OK with arm64 binaries.

Any advice?

[Matthias Bläsing]

Hi,

you are basicly attempting a cross build. All my builds were same
architecture builds. To build the native libraries for windows, I have
the Visual C++ Tools and two cygwin installations (cygwin 32 and cygwin
64 are both install) on my system.

The native libraries can be build without the MSVC tools, but that is
mostly untested.

My setup is described here:

https://github.com/java-native-access/jna/blob/master/www/WindowsDevelopmentEnvironment.md

I assume, that you'll need at least mingw with arm64 as target
architecture.

Greetings

Matthias

[Tres Finocchiaro]

Matthias,

Thanks kindly for the link to the build instructions.  I've modified them slightly to allow using CMD to setup the vars, and then invoke the cygwin tools through ant/make.  This seems to be viable, here's my progress so far: https://gist.github.com/tresf/d07a3d78020a5fa1d238fe75c2f323e5

In short, the aarch64 build system seems to be functioning now, but  it's failing when linking 'src/x86/win32.lo', which I can only assume is because that dependency is building for the wrong architecture.

Any advice is greatly appreciated.

-Tres

- Tres.Fin...@gmail.com

[Tres Finocchiaro]

I assume, that you'll need at least mingw with arm64 as target architecture.

This was my initial fear because I don't think there's an easy way to get mingw which targets arm64.  Please correct me if I'm wrong... 

https://github.com/msys2/MSYS2-packages/issues/1787

Last I looked, I believe llvm had one, but I'm fearful of the effort it would take to get working -- at least on a Windows environment.

This is why I went down the MSVC route, but if gcc is a hard requirement, I may need to work with clang instead.

 

- Tres.Fin...@gmail.com

[Matthias Bläsing]

Hi,

Am Freitag, den 24.07.2020, 13:46 -0400 schrieb Tres Finocchiaro:
> This is why I went down the MSVC route, but if gcc is a hard
> requirement, I may need to work with clang instead.

ähm - clang != gcc, so I have some doubts.

What you could do first: Check Upstream libffi and see if there is
support for windows on arm64. If so, have a look how that works.
Updating libffi is an option if there is a good reason.

Maybe there are also instructions how to crossbuild or prebuild
binaries can be found - then only loading a system libffi for windows
is necessary.

Greetings

Matthias

[Tres Finocchiaro]

> ähm - clang != gcc, so I have some doubts.

Agreed, it may bring other build failures, but their mingw does have an arm64 target: https://github.com/mstorsjo/llvm-mingw/blob/master/README.md

 libffi and see if there is support for windows on arm64

It is since fall 2019, so I'm rebuilding with that to see if it helps the errors I'm receiving.

[Tres Finocchiaro]

The latest libffi has new errors and it appears it may be caused by msvcc.sh having either missing and/or bad compile flags for assembly (this is just a guess after reading some bug reports) although the age of these conclusions range from 1 to 9 years old, so that's speculative.

As a result, there is a CMake PR available -- a technology I'm much more familiar with -- but even if successful, I'm not certain I'll know where to properly place the files or how I'd ask ant to use those that are already generated, but that will be the next attempt.

My latest (non-working) instructions are still on the gist linked above.  If CMake works, I'll update accordingly.

- Tres.Fin...@gmail.com

[Tres Finocchiaro]

Slightly off-topic, but quoting the main project page:

If you are interested in paid support, feel free to say so on the jna-users mailing list. 

I'd like to invite any interested JNA developers to reach out to me directly at tr...@qz.io if available for paid support to improve Windows aarch64.

- Tres.Fin...@gmail.com

[Tres Finocchiaro]

So, I've managed to get the build system working with Windows arm64 compiler and the latest libffi (required some patches to msvcc.sh) however I'm still stuck at compiling dll-callback.c whom's source reads:

Must use mingw64 to compile this assembly code.  ml64 can't generate the RIP-relative jumps we need.

 ... which brings back to the original question... 

> Is this "inline assembly" going to cause build issues with ARM?  Last I checked, mingw didn't have a Windows ARM version unless it's built with Clang however since the tutorial references Cygwin, I assume it's built with gcc, no?

Is Windows arm64 support not possible without an arm64 version of mingw64, or is this a historical decision that can be fixed with changes to the build scripts?

- Tres.Fin...@gmail.com

[Timothy Wall]

I'd recommend tweaking the Makefile instructions to simply leave it out.  IIRC, that section was intended to support DLL callbacks but was never fully implemented (it would require instantiating a VM in the context of the DLL and then loading whatever Java callback code you're attempting to run).

T.

--

You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/CANQs7dA%3DO0pmws_ZGSJEZJJfLuJLU1DSkNnTtaFwjHP3RsJYOA%40mail.gmail.com.

[Tres Finocchiaro]

Fantastic, thanks!  We'll remove and report our success.

- Tres.Fin...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/CADgGZ6F%2Bsuq7PHWp%3D-Ndfdq4y8i%3DhfOUgQr-Os2TDFKgG78_cg%40mail.gmail.com.

[Tres Finocchiaro]

I'd recommend tweaking the Makefile instructions to simply leave [dll callbacks] out.

Do you have any pointers?  jnidispatch seems to rely on callback.c, which has hard-coded functions from callback.c such as JNA_callback_init, so it must be included.

I tried making a stub callback.c but then the asmfnX and friends are missing.

Is there a preprocessor flag I should be setting to skip this stuff or do I need to write my own? (I'm not a C developer, so any pointers here are greatly appreciated).

[Tres Finocchiaro]

Ok... for now I think I can avoid the asmfnX's by compiling callback.c with _WIN32_WCE flag set.

I now have a jnidispatch.dll built with MSVC that claims to target ARM64.  Using Microsoft's ARM64 build of Java, I'll test it.  If it works, I'll create a PR.

I hope the devs are OK guiding the PR to something mergeable.

[Tres Finocchiaro]

Using Microsoft's build of openjdk, I can successfully read the Windows registry.  PR to follow.

- Tres.Fin...@gmail.com

[Tres Finocchiaro]

PR submitted.  We can continue the discussion there: https://github.com/java-native-access/jna/pull/1264

- Tres.Fin...@gmail.com