Targeting aarch64-unknown-none-elf


#1

Hey-o!

I’m been starting to get into some lower level programming, and found these great reference points:

Writing an OS in Rust

intermezzOS

The only difference is, I’m wanting to hit the latest ARM chip on the rpi 3, which is ARMv8 with cortex-a53 and neon-fp-armv8.

I’m trying to setup a toolchain for aarch64-unknown-none-elf, as the title suggests, but am running into trouble once cmake starts trying to compile it’s little test C and C++ programs. What I’ve done so far…

Painstakingly scoured the internet for info to figure out how to correctly build the latest GNU toolchain for aarch64-none-elf.

I’ve successfully built and loaded a hello world into qemu with a cortex-a57 CPU emulation piping some stuff into uart0 with this toolchain to test it was setup correctly. However, gcc, as, and ld were all invoked by hand, and -c was passed to gcc when compiling.

Now, onto setting it up through Rust…

I’ve forked and cloned the repo, added a makefile for my target in mk/cfg and configured with:

configure --prefix=/home/nathan/development/tools/aarch64 --target=aarch64-unknown-none-elf --disable-jemalloc

(The prefix is the same location the GNU chain is installed, and it is all in my $PATH).

It starts to fail when cmake starts trying to compile it’s “simple C program” located here

~/aarch64/build/rust/aarch64-unknown-none-elf/rt/compiler-rt/CMakeFiles/3.0.2/CompilerIdC/CMakeCompilerId.c

I get the following error

cmake: compiler-rt
-- The C compiler identification is GNU 6.1.0
-- The CXX compiler identification is GNU 6.1.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/nathan/development/tools/aarch64/bin/aarch64-none-elf-gcc
-- Check for working C compiler: /home/nathan/development/tools/aarch64/bin/aarch64-none-elf-gcc
-- Check for working C compiler: /home/nathan/development/tools/aarch64/bin/aarch64-none-elf-gcc -- broken
CMake Error at /usr/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler
  "/home/nathan/development/tools/aarch64/bin/aarch64-none-elf-gcc" is not
  able to compile a simple test program.

  It fails with the following output:

   Change Dir: /home/nathan/development/tools/aarch64/build/rust/aarch64-unknown-none-elf/rt/compiler-rt/CMakeFiles/CMakeTmp

Trying to re-create the steps myself, when invoking gcc without the -c flag, I also get a string of errors when it starts looking for various libs.

When building the GNU toochain, I supplied the --disable-multilib flag, because I did not expect gcc to handle the post steps for me.

What do I need to do in order to get rustc compiled in the same way? Do I need to edit the cmake to add the -c flag when testing its programs during the build stage? If so, how do I go about that?

Thanks in advance for any help!


#2

See http://blog.rust-lang.org/2016/05/13/rustup.html , https://github.com/japaric/rust-cross for information on how to do cross-compilation. You don’t need to build rustc yourself (and it doesn’t really even help); any rustc downloaded from rust-lang.org can build code for any target.


#3

Thanks for the suggestion, but I’m already aware of rustup, and rust-cross doesn’t cover cross compiling anything the compiler doesn’t support out of the box.

Unfortunately, I do need to build it myself if I want to hit that target, because it is not supported at the moment. To see what targets are, you can check here mk/cfg


#4

rust-cross does in fact cover targets which aren’t supported out of the box… see https://github.com/japaric/rust-cross#target-specification-files and https://github.com/japaric/rust-cross#cross-compiling-no_std-code , and maybe https://github.com/japaric/xargo.

Also, you can probably get away with just using the aarch64-unknown-linux-gnu target; code generated using that target should be usable on bare-metal as long as you’re using #![no_std].


#5

The JSON things looks interesting, I’ll check that out when I get home. I just saw this in the rust-cross README:

NOTE If your target is not supported by the RBS, then you’ll need to add support for your target to it. I won’t go over the details of adding support for a new target, but you can use this PR as a reference.

And quit reading. Glad you made me take another look.

If I don’t get any further along with those suggestions tonight, I’ll just make use of unknown linux target.