LLVM - ARM cross-compilation using Raspberry!!

Well, a short break on continuous integration posts!

I bought my Raspberry Pi (http://www.raspberrypi.org/) board some weeks ago mainly to use it as a developer board (pretty affordable and efficient). So, I decided to use it to cross-compile LLVM (http://www.llvm.org).

So, here you go.

Building

First of all, download LLVM (from either SVN or GIT repositories). I got the following information from  LLVM documentation. For more details, check this out!

• Checkout LLVM:
  $ cd where-you-want-llvm-to-live
  $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
  
• Checkout Clang:
  $ cd where-you-want-llvm-to-live
  $ cd llvm/tools
  $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
• Checkout Compiler-RT:
  $ cd where-you-want-llvm-to-live
  $ cd llvm/projects
  $ svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
• Get the Test Suite Source Code [Optional]
  $ cd where-you-want-llvm-to-live
  $ cd llvm/projects
  $ svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite

To cross-compile it to ARM platform, you need a toolchain. I use Sourcery G++ Lite 2011.03-41 (MentorGraphics Sourcery CodeBench Lite Edition) - it is free and contains everything we need. Install it and also remember to set the PATH variable so that you can use your toolchain.

$ export $PATH=$PATH:/home/user/CodeSourcery/Sourcery_G++_Lite/bin

Now, it´s time to build the application (and remember: for further details, check this out!)

$ cd where-you-want-to-build-llvm
$ mkdir build (for building without polluting the source dir)
$ cd build
$ ../configure --target=arm-none-linux-gnueabi --host=arm-none-linux-gnueabi --enable-optimized (the target/host value may change depending on the toolchain that you have chosen.)
$ make

Now, you just need to wait for a couple of minutes :-) Next step is NFS-mounting the LLVM dir in your Raspberry Pi.

NFS-Mounting

Now, LLVM is cross-compiled and we are able to use it and perform some tests on Raspberry Pi. I prefer NFS as partition mounting solution. An important information is that you have to have the same path on both environments (desktop and remote). It means that if you are building LLVM on /home/user/llvm desktop folder, you have to mount it on /home/user/llvm remote folder (in most of cases, you have to create the user on your Raspberry environment - just use the command).  Firstly, set up your desktop machine:

• Install NFS packages
  @desktop$ sudo apt-get install portmap nfs-kernel-server nfs-common
• Edit /etc/exports and add the following line
  /home/user/llvm 192.168.1.0/24(rw,sync,no_subtree_check)
• Restart NFS system
  @desktop$ sudo service nfs-kernel-server restart
• Change access permission of your shared folder (in this case, I use the same folder)
  @desktop$ chmod -R 777 /home/user/llvm

Configuration on Raspberry Pi is also straightforward:

• Install NFS packages (most of Raspberry distributions contain NFS installed, so maybe this step is not necessary)
  @remote$ sudo apt-get install portmap nfs-kernel-server nfs-common
• Create the host folder
  @remote$ mkdir llvm
  @remote$ chmod 777 llvm
• Mount the NFS-shared folder
  @remote$ sudo mount 192.168.1.4:/home/user/llvm /home/user/llvm

Now it is done and you can use your cross-compiled LLVM on your Raspberry.

Testing

Let´s now focus on LLVM tests and how we can run them on ARM platforms. In this case, I am running tests under /home/user/llvm/tests folder.

• CD to test dir
  @remote$ cd llvm/build/test
• Run tests
  @remote:/home/user/llvm/build/test$ make 

After some minutes, LLVM test suite runs all integration tests and provides a report with results.

@remote:/home/user/llvm/build/test$ make
...
PASS: LLVM :: ExecutionEngine/MCJIT/test-shift.ll (59 of 59)
Testing Time: 11.65s
********************
Unexpected Passing Tests (1):
    LLVM :: ExecutionEngine/MCJIT/test-data-align-remote.ll
********************
Failing Tests (7):
    LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll
    LLVM :: ExecutionEngine/MCJIT/2005-12-02-TailCallBug.ll
    LLVM :: ExecutionEngine/MCJIT/fpbitcast.ll
    LLVM :: ExecutionEngine/MCJIT/pr13727.ll
    LLVM :: ExecutionEngine/MCJIT/test-call.ll
    LLVM :: ExecutionEngine/MCJIT/test-common-symbols.ll
    LLVM :: ExecutionEngine/MCJIT/test-ret.ll
  Expected Passes    : 45
  Expected Failures  : 6
  Unexpected Passes  : 1
  Unexpected Failures: 7

UPDATE: Raspberry Pi the ARM target platform for LLVM project at this moment. If you want to contribute to LLVM project by supporting ARM features, check a PandaBoard development kit.

Setting up your Continuous Integration environment - Part I

Continuous Integration is such a great idea: it works as a trainee that constantly downloads/builds/tests/deploys you application and notifies you whether something goes wrong or nice. I really do believe that (of course, besides several other advantages) it improves the project overall quality and also helps you to keep the application ready to be reviewed by a stakeholder.

If you are still skeptical about it, please take a look that this marvelous post here [Martin Fowler] .

Let´s discuss how you can set up a environment for a more complex project. So, unfortunately, this is tutorial for beginners (for basic/how-to-install-and-run instructions, check it on internet).

Introduction

The system consists of one server located in a external environment (for example, AWS services) and several mobile clients (iOS, Android and QT clients). Basically, the mobile applications fetch content/data from the server.

We need to constantly build/deploy the server and build all mobile clients. One very interesting point in this scenario is the amount of platforms: iOS (to build iOS client), Linux (to build Android/QT client - I´d rather use Linux for Android projects) and Windows (to build the server).

Besides svn checking-out + building + testing + deployment, we will also use QA solutions, such as Sonar and some static analysis tools for different platforms.

We will use Jenkins as CI server.

Proposed design


As I said, the system consists of several components: mobile clients (iOS, Qt and Android) and also servers. In this case, I´d rather use master-slave approach. You can create one slave for each mobile platform and also another one for for servers. To the given example, the solution is defined as it follows:

You might ask me why this is too complicated! But believe on me. If you have complex systems to build, this approach works a lot better: it´s easier to organize and to maintain, and each component on its own environment. In my next post, I describe how we set up all of this :-)

Back!!!

After a loooong break, I am back to this. I have to confess that I had had several new/cool stuff during this pause: new projects, mind-blowing findings, exciting/stressful experiences, lovely/irritating people. And all of this had consumed a lot of my free time. I am not saying that I hadn´t had time at all: I had done some new/different things with such slots of time than only writing about technical stuff.

Well, but anyway, let´s keep track of new stuff. The main reason to start blogging again was the simply fact that I am not used to describe all solutions for tricky problems in general: how to cross-compile certain applications for ARM devices, how to set up a smart CI environment, and so forth. I swear I have tried it really hard, but my evil side always tells to myself: "if you need it some other day, you will remember it". So, this is also a kind of "Raul´s Recipes Book".

I am really convinced that it will work :-)

As part of my next posts, I will describe a bit more about how lovely is a CI environment for a relative huge project (of course, how you can set up all of this and put the pieces together). Specially, when it has such different clients, such as iOS, Android and QT applications.