Build failing on arm64

[thiagogcm]

I'm trying to compile GraalVM with sulong using mx --dynamicimports /sulong build

Build fails with:

In file included from /home/tic/graal/sulong/tests/com.oracle.truffle.llvm.tests.sulong/c/intrinsics/movemask.c:30: error: invalid conversion between vector type '__m64' (vector of 1 'long long' value) and integer type 'int' of different size

After ignoring the tests files I get a bunch of

error: invalid output constraint '=a' in asm

[pekd]

There are two problems when building Sulong on ARM64:

• the bitcode files (and reference executables) of test cases are built using the host's toolchain and some of them use x86_64 inline assembly / syscalls / ISA extensions like SSE or AVX
• Sulong needs the libsulong libraries (there is a bitcode part and a native part); both are tightly coupled with the Java code of Sulong and the bitcode part/Java code expect magic constants (like syscall numbers) for x86_64.

Bitcode itself is not platform independent, if you build bitcode on ARM64 it's different than if you build it on x86_64. Important differences are data types and certain constants. A long time ago when I tried to get Sulong running on ARM64, I had to remove all test projects (including the pipe project). In the end it could run simple hello world style programs but everything more complex didn't really work.

You will run into problems because Sulong calls native functions of the underlying libc if there is no bitcode function available. Magic constants are different between platforms, so this will not work in some cases and lead to unexpected behavior. If you build your bitcode on ARM64, the inline assembly interpreter in Sulong will be totally confused because it expects x86_64 code. If Sulong intercepts/performs a syscall, it also expects an x86_64 host system and a bitcode file for x86_64.

For now, you probably won't have that much fun with Sulong on ARM64 even if you manage to compile it.

[rschatz]

Technically, the above comment is correct, but it's not quite as bad as it sounds.

Sulong, as a bitcode interpreter, should in principle work on all architectures (for now, only little-endian ones, but that should be fine on ARM).

One thing that will not work is inline-assembly and architecture specific intrinsics. As long as you don't use these (and also make sure the compiler won't produce them through optimizations), the bitcode should run using Sulong.

Also, direct syscalls won't work. That's the source of the invalid output constraint errors. They are internally used by the exit, abort and clock_gettime intrinsics in Sulong (in projects/com.oracle.truffle.llvm.libraries.bitcode). You'd have to hide these behind #ifdef to get libsulong.bc to compile. It's a bit of a hack to remove these, at least exit and abort are critical to be intrinsified, we don't want a user call to exit or abort to kill the whole VM. But it should be enough to get something running.

What should work though is calls to the libc. Just make sure the bitcode files you're running are compiled against the same libc than GraalVM itself, so method signatures, magic constants and so on match. As long as your code doesn't use any architecture specific inline assembly and syscalls, it should work fine.

The compiler errors in the tests are expected, some of our tests are AMD64 specific. You can ignore those.

Of course all off that comes with the big disclaimer: We don't test on ARM64, so I would be surprised if everything worked flawlessly on the first try. Expect to find plenty of bugs ;)

Another possibility to get Sulong running on different platforms is cross-compiling your program to x86_64 bitcode, and then cross-execution that on all other platforms. In principle, that should work, since Sulong is written in Java, but there's a big catch: When you do that, you can't call any native functions. That means you need everything you execute in bitcode form, that's including the libc. Even then, syscalls are not going to work out of the box. But depending on your use-case that might be fine. If your program is just shuffling around data, but not doing any IO, that could still work.