rustc, ELF, ld...

Hello, I had a go at trying to run rustc output (from Linux) on RISC OS.

cargo rustc -- --target=armv7a-none-eabi --verbose

produces an ELF file with correct code in (my test program has standard library and C runtime disabled, so it’s pure ARM), and everything looks ok to me using objdump.

When I run it on RISC OS however the .text segment doesn’t end up in the right place. The error is “Undefined instruction at &20114”, which makes sense as
objdump says _start is at 0×20114 (.text starting at 0×200e4), and I did *InitStore first, but inspecting memory I see that in fact .text is placed at &8000 (nothing else appears to have been loaded apart from the ELF header at &8000 then overwritten by the .text section).

I’m hoping someone who understands ELF and ld a bit better than me can help here?!

In case anyone else wants a go, here is my main.rs:

#![feature(lang_items)]
#![no_std]
#![no_main]

use core::panic::PanicInfo;

#[lang = "eh_personality"]
fn rust_eh_personality() {
}

#[panic_handler]
fn panic(p: &PanicInfo) -> ! {
  loop {};
}

fn h() {
  loop {}
}

fn g() {
  let mut x = 3;
  x = 4;
  h();
}

#[no_mangle]
pub extern "C" fn _start() -> ! {
  let mut x = 5;
  x = 6;

  g();
  loop {}
}

Also to actually get the target to work I had to do

rustup override set nightly
rustup target add armv7a-none-eabi

Hummm sounds like something may not right with some PT_LOAD segment maybe?

What readelf shows?

Have you compared the header with what is generated by GCC when a module is compiled without SCL/UnixLib support?

Also remember that in Rust:

#![no_std]

surely compile without std support, but it still uses core (which is kind of a subset of std), so it is possible that maybe core is causing some linking issues?

Hummm sounds like something may not right with some PT_LOAD segment maybe?

What readelf shows?

This is what it looked like (linked with default, rust-lld)

start address 0x0002014c

Program Header:
    PHDR off    0x00000034 vaddr 0x00010034 paddr 0x00010034 align 2**2
         filesz 0x000000a0 memsz 0x000000a0 flags r--
    LOAD off    0x00000000 vaddr 0x00010000 paddr 0x00010000 align 2**16
         filesz 0x000000e4 memsz 0x000000e4 flags r--
    LOAD off    0x000000e4 vaddr 0x000200e4 paddr 0x000200e4 align 2**16
         filesz 0x00000088 memsz 0x00000088 flags r-x
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**0
         filesz 0x00000000 memsz 0x00000000 flags rw-
0x70000001 off    0x000000d4 vaddr 0x000100d4 paddr 0x000100d4 align 2**2
         filesz 0x00000010 memsz 0x00000010 flags r--
private flags = 5000200: [Version5 EABI] [soft-float ABI]

I figured ld in the gccsdk cross-compiler knows how to produce the right arrangement, so I built using

cargo rustc -- --target=armv7a-none-eabi --verbose -C linker="/path/to/arm-unknown-riscos-gcc" -C link-arg="-nostdlib"

(the -nostdlib is to stop it trying to put crt0.o in), but ld ((GCCSDK GCC 4.7.4 Release 5) 2.24) terminated with a segmentation fault.

I put autobuilder to work on gcc8 which gave me an ld (GNU Binutils) 2.30, and using

cargo rustc -- --target=armv7a-none-eabi --verbose -C linker="/path/to/arm-riscos-gnueabihf-ld" -C link-arg="-nostdlib"

I get an ELF looking like

start address 0x00008110

Program Header:
0x70000001 off    0x00000130 vaddr 0x00008130 paddr 0x00008130 align 2**2
         filesz 0x00000008 memsz 0x00000008 flags r--
    LOAD off    0x00000000 vaddr 0x00008000 paddr 0x00008000 align 2**15
         filesz 0x00000138 memsz 0x00000138 flags r-x
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
         filesz 0x00000000 memsz 0x00000000 flags rw-
private flags = 5000200: [Version5 EABI] [soft-float ABI]

which seems much more satisfactory. Getting a little excited now, I tried running it in RISC OS and it didn’t crash, and the memory at &8000 is just the ELF as expected. To prove it really worked, I modified the function h in main.rs to

fn h() {
  unsafe {
    let x: *mut u8 = ptr::null_mut().offset(0x8000);
    *x = 33;
  }

  loop {}
}

and after running it *Memory 8000 shows

00008000 : !ELF : 464C4521

:D

nice work! :)

Looking at the possibility of porting libstd to RISCOS, I tried compiling my test program with

cargo rustc --target=armv7-unknown-linux-gnueabihf --

which complained that librt, libdl and libutil were not available. I didn’t find those libraries in the gccsdk autobuilder (I satisified other dependencies that are provided by gccsdk by appending ‘-C link-args=“…”’). There was a step in the middle where I cross-compiled libstd, but I don’t remember the command now, I think it might be using rustup. I also used a custom json target file at some point:

cat armv7-unknown-linux-gnueabihf.json 
{
  "abi": "eabihf",
  "arch": "arm",
  "crt-static-respected": true,
  "data-layout": "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64",
  "dynamic-linking": true,
  "env": "gnu",
  "executables": true,
  "features": "+v7,+vfp3,-d32,+thumb2,-neon",
  "has-elf-tls": true,
  "has-rpath": true,
  "llvm-target": "armv7a-none-eabi",
  "max-atomic-width": 64,
  "os": "linux",
  "position-independent-executables": true,
  "relro-level": "full",
  "target-family": [
    "unix"
  ],
  "target-mcount": "\u0001__gnu_mcount_nc",
  "target-pointer-width": "32"
}

So I think we’d need to either satisfy the above dependencies or somehow switch off those bits (It looks to me like they’re actually dependencies of rusts’s libc, studying the source code.)

which complained that librt, libdl and libutil were not available.

Yes librt is the PSOIX.4 API for real time extensions. In rust it should be used by clock_gettime (and yes rust should not link to it by default, no idea why it does!), anyway, maybe it may be easy to replace? (guessing!)

libdl is the dynamic linking library (it is used by dl_iterate_phdr and obviously by libloading.rs), it should be available, we just used it for RiscLua and it’s working fine.

libutil, if not available, should be easy to port, there is already a tested armv7-none-eabi-* somewhere, I remember I have used it for another project…

Few obvious questions:

• Did you try to pass

  —as-needed

  to the linker?
• Did you try to use

  -Z no-landing-pads

  ? (just out of curiosity)

JFYI, this guide is what I use when cross compiling with Rust, it may have some useful info: https://github.com/japaric/rust-cross