CoreCLR building on ARM

[benpye]

This PR allows for CoreCLR to be built on ARM. It has been tested on Ubuntu 14.04 on a Raspberry Pi 2 but should work on any reasonably similar Linux distribution with ARMv7, VFPv3 and Thumb 2 support. All PAL tests pass and I believe this would be in a suitable state for CI as it builds cleanly.

The JIT is as of this PR non functional, however, to enable bring up of other components it is possible to use the legacy JIT. This can be enabled by modifying the src/jit/CMakeLists.txt file, so that the following is under elseif(CLR_CMAKE_PLATFORM_ARCH_ARM) (line 74).

set( ARCH_SOURCES
  targetarm.cpp
  unwindarm.cpp
  emitarm.cpp
  codegenlegacy.cpp
  registerfp.cpp
)
add_definitions(-DLEGACY_BACKEND) 

With the legacy JIT backend, this PR actually gets the ARM port to the point of running a simple hello world application, though there is still issues in stack unwinding so GC and exception handling at the very least are still non functional. I have gotten further in another branch, however I am currently blocked by a Clang bug (see https://llvm.org/bugs/show_bug.cgi?id=24146 ).

The sos plugin for lldb will build on ARM however lldb itself will not work on ARM, instead segfaulting when trying to execute corerun. This is an lldb bug and when lldb is fixed, it should be possible to use sos to debug CoreCLR on ARM, though there may be issues.

[kangaroo]

armv7l is little-endian armv7, but you seem to be targeting hard-float ABI, which is (generally) known as armv7hl. Perhaps this isn't consistent across kernels/cmakes? Can you add armv7hl as well?

[benpye]

Can add it, but I haven't seen any example of having uname output armv7hl?

[josteink]

Just to add some real world data. Raspbian (which is hard-float) running on a classic Raspberry pi (1) gives the following output:

$ uname -a
Linux Applepi 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux

Note there is no armv6hl in the output. Not sure if this is enough data to base a generalization on, but at least it's data :)

[benpye]

Unfortunately ARMv6 is going to be harder to support. So currently only the
RPi 2 will work at this time.

On Fri, 24 Jul 2015 09:27 Jostein Kjønigsen [email protected]
wrote:

In CMakeLists.txt
#1210 (comment):

@@ -16,7 +16,16 @@ set(VM_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src/vm)

if(CMAKE_SYSTEM_NAME STREQUAL Linux)
set(CLR_CMAKE_PLATFORM_UNIX 1)

• set(CLR_CMAKE_PLATFORM_UNIX_TARGET_AMD64 1)
• if(CMAKE_SYSTEM_PROCESSOR STREQUAL x86_64)

•    set(CLR_CMAKE_PLATFORM_UNIX_TARGET_AMD64 1)
  

• elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL armv7l)

Just to add some real world data. Raspbian (which is hard-float) running
on a classic Raspberry pi (1) gives the following output:

$ uname -a
Linux Applepi 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux

Note there is no armv6hl in the output. Not sure if this is enough data
to base a generalization on, but at least it's data :)

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/coreclr/pull/1210/files#r35404087.

[josteink]

I have no problems with that. Just supporting your notion that hard-float (as brought up by @kangaroo) often doesn't show in uname -a.

[Tragetaschen]

Just to add to the confusion :)

I'm targeting a Freescale i.MX 6DualLite (with VFPv3) using a hard-float toolchain from the Yocto project.

$ uname -a
Linux f500-kai 4.0.0-00146-g52ee60d-dirty #45 SMP Thu Jul 23 16:20:44 CEST 2015 armv7l GNU/Linux

[benpye]

Would it be viable to merge this if I disabled the use of LEGACY_BACKEND? It would result in this being mostly non functional (hitting an NYI in lowering IIRC), but it wouldn't use the legacy code, would stop the build being broken at the very least, and could enable @kangaroo to get somewhere getting his changes merged. I (and potentially others) would then be able to submit further PRs to get the JIT to a working state.

[BruceForstall]

What you suggest is very reasonable.

Certainly, the ARM LEGACY_BACKEND code exists, and is very functional and complete. There's no reason you can't use it to make progress on other parts of the port. I just want to be clear that long-term, we want it to go away in favor of a full RyuJIT ARM port.

One option is to go ahead and merge with LEGACY_BACKEND enabled. I wouldn't want us to commit to keeping it building and working, though, so I wouldn't want to see a CI build and test with this defined. Another option is to merge with this not enabled, but people working on an ARM port could enable it locally to make non-JIT progress while a full RyuJIT port is also worked on.

[jkotas]

@benpye I think that this PR is pretty close. I would suggest that it is prepared for merge: Edit the title and PR description, resolve conflicts, and cleanup the history - maybe squashing it into single commit would be easiest.

I am not sure whether there are still any contentious changes that needs to be fixed up - if there are any, I would recommend to exclude them from this PR and move them into the next one.

[kangaroo]

I agree with @jkotas, I think after a cleanup and squash we can do one more pass for minor things.

[benpye]

Squashed down to three commits, split out the va_list changes as that was a violation of the C specification, and the test fix as that was an error regardless. @jkotas @kangaroo

[benpye]

@janvorli I believe I have fixed the few issues you picked up upon, is there anything else or shall I squash down again?

[janvorli]

@benpye I am fine with it. Thanks a lot again for all the work!

[benpye]

Squashed again down to the 3 commits.

[benpye]

And merge conflict fixed, System.Security.Cryptography.Native was moved to corefx but the changes I made seem to not be applicable there anyway as they have removed the -DBIT64 definition.

[jkotas]

Thank you for getting this done and incorporating all feedback!

[OtherCrashOverride]

Now that its merged, can someone provide a synopsis of what is accomplished? Does this make AArch32 JIT and execute HelloWorld?

[benpye]

@OtherCrashOverride See my last comment on #1192 , I think it covers what you are asking.

[OtherCrashOverride]

@benpye Thank you for your response and your work on this.

[benpye]

@BruceForstall just to check I'm not duplicating effort, you mention the ARM RyuJIT got to "Hello World" before, is that the code here or is that sitting on some feature branch somewhere as going through this, I don't see how it could of reached that point in the past.

[BruceForstall]

It's been a long time since we've worked on the ARM RyuJIT port, so it's probably regressed (or just bit rotted). The code is in CodeGenArm.cpp. Most likely, this would need to be updated to pick up structural changes from either CodeGenxarch.cpp (from the shipping RyuJIT x64 port), and/or from CodeGenArm64.cpp, the further-along ARM64 port. Note that the RyuJIT ARM port is missing fundamental things right now, such as codegen support for HFA calling convention, and register allocation support for long (64-bit int) types. We'll need to add support for longs when we port to x86, as well, and we do have a plan for that going forward. For simple code generation, doing intelligent "porting" from the ARM64 port might be the best way to make progress.

[gitchomik]

@benpye Thank you for your your work on this.

Please tell me, how did you compile System.Native.so ?
I just looked at your commit dotnet/corefx@e16fbb7

Did you compiled System.Native.so on Raspbery Pi 2 ? or did you cross compiled it on Ubuntu ?
Is it possible to add cross compile support for it ?

[benpye]

I compiled it on the target, I'm using a Jetson TK1 now, but a Raspberry Pi 2 should work too. Sorta discussed the issue at #1344 but maintaining the build system for native components in coreclr and corefx is non sustainable, especially now cross compilation is supported for coreclr, but not corefx, but it seems foolish to just duplicate everything. A solution will be found in the end I hope.

[gitchomik]

@benpye Thanks for your response. Regards.