xtensa triple

[MabezDev]

I'm experimenting with Rust using this llvm fork.

As Rust relies on llvm for codegen it won't be possible to actually generate binaries until that is implemented but I thought I would start working on it now.

For a given Rust target specification an llvm triple must be specified, I've tried many triples, e.g xtensa-unknown-unknown and none have worked thus far.

I'm not familiar with the process of adding a target to llvm so is this something that will be added when object generation is implemented?

[andreisfr]

@MabezDev, currently --target=xtensa option should be used to generate asm files. Why you need a triple form of target specification? Did you try just specify "xtensa" as target?

Regarding your question, some target triple for xtensa will be added in next updates.

[MabezDev]

As per the advanced embedded rust book the rust target specification requires a llvm triple, not a target. Hence "xtensa" doesn't work.

I look forward to the triples being added, running Rust on the ESP32 will be awesome.

Thanks for the work so far.

p.s is there a timescale on these updates? are PR's welcome?

[igrr]

@MabezDev with regards to

As Rust relies on llvm for codegen it won't be possible to actually generate binaries until that is implemented

One option you have at the moment is to write a wrapper program (shell script, Python, rust — anything will do) which would pose as a clang executable, and would do three things:

1. "tweak" the options, if necessary — replace -c with -s, maybe replace target specification (xtensa-unknown-unknown to xtensa)
2. call real clang with -s flag to generate an assembly file
3. call xtensa-esp32-elf-as to generate the object file

I've used similar approach while testing the current clang with esp-idf, where the wrapper script would also filter out gcc-specific flags which were passed from the build system.

PRs are certainly welcome! Before doing large changes though, please coordinate with us here or on the forum, just in case we are also working on something related — to reduce potential merge conflicts.

We will try to push out some changes from our end every week or two.

[andreisfr]

@MabezDev, you could also try to use "xtensa-unknown-elf" triple together with wrapper program. But elf is doesn't generated now, just asm output

[MabezDev]

@MabezDev, you could also try to use "xtensa-unknown-elf" triple together with wrapper program. But elf is doesn't generated now, just asm output

Unfortunately this target didn't work either:

RUSTC=/home/mabez/development/esp32-rust/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustc cargo build --target xtensa
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/home/mabez/development/esp32-rust/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustc - --crate-name ___ --print=file-names --target xtensa --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: Could not create LLVM TargetMachine for triple: xtensa-unknown-elf: No available targets are compatible with this triple.

Based on this rust target specification:

{
    "abi-blacklist": [
        "stdcall",
        "fastcall",
        "vectorcall",
        "thiscall",
        "win64",
        "sysv64"
    ],
    "arch": "xtensa",
    "data-layout": "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64",
    "emit-debug-gdb-scripts": false,
    "env": "none",
    "executables": true,
    "is-builtin": false,
    "linker": "/home/mabez/programs/xtensa-esp32-elf/bin/xtensa-esp32-elf-ld",
    "linker-flavor": "gcc",
    "llvm-target": "xtensa-unknown-elf",
    "max-atomic-width": 32,
    "os": "none",
    "panic-strategy": "abort",
    "relocation-model": "static",
    "target-c-int-width": "32",
    "target-endian": "little",
    "target-pointer-width": "32",
    "vendor": "none"
}

One option you have at the moment is to write a wrapper program (shell script, Python, rust — anything will do) which would pose as a clang executable, and would do three things:
"tweak" the options, if necessary — replace -c with -s, maybe replace target specification (xtensa-unknown-unknown to xtensa)
call real clang with -s flag to generate an assembly file
call xtensa-esp32-elf-as to generate the object file
I've used similar approach while testing the current clang with esp-idf, where the wrapper script would also filter out gcc-specific flags which were passed from the build system.

If I can get Rust to detect the xtensa triple, Rust has an option to emit llvm-ir. It should be possible to generate asm then object files from that. Sadly still not having much luck on that front.

[igrr]

I suppose changing

"llvm-target": "xtensa-unknown-elf",

to "xtensa" would not work for some other reason?

[MabezDev]

Yeah just xtensa doesn't work either, same error.

[igrr]

Can you please try running cargo under strace -f to determine which command line arguments are being passed to llvm?

Nevermind, I see now rust doesn't call the llvm executable, it links to the library instead. And fails in LLVMRustCreateTargetMachine trying to do TargetRegistry::lookupTarget (https://github.com/rust-lang/rust/blob/f47ec2ad5b6887b3d400aee49e2294bd27733d18/src/rustllvm/PassWrapper.cpp#L346).

[MabezDev]

So I've added theses tests to make sure llvm can understand the triples:

diff --git a/unittests/ADT/TripleTest.cpp b/unittests/ADT/TripleTest.cpp
index ed4a88067b1..c9970fb2bd2 100644
--- a/unittests/ADT/TripleTest.cpp
+++ b/unittests/ADT/TripleTest.cpp
@@ -248,6 +248,16 @@ TEST(TripleTest, ParsedIDs) {
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());

+  T = Triple("xtensa-unknown-unknown");
+  EXPECT_EQ(Triple::xtensa, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("xtensa");
+  EXPECT_EQ(Triple::xtensa, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
   T = Triple("lanai");
   EXPECT_EQ(Triple::lanai, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());

and they work as expected.

I assume clang uses the same lookupTarget internally so I am not sure why Rust is having issues.

[MabezDev]

So I got Rust to detect the xtensa target, I wasn't registering the target within the Rust compiler (https://github.com/mabezdev/rust/blob/xtensa-target/src/librustc_llvm/lib.rs#L111).

I can now build the core crate llvm-ir/asm, unfortunately when building with xtensa-esp32-elf-as core.s -o xtensa-core-bin I get thousands of these relocation errors:

core-3704b16aa5ea1124.s: Error: unhandled local relocation fix BFD_RELOC_64

Any ideas?

[igrr]

Could you please upload this core-3704b16aa5ea1124.s file somewhere so that we can have a look?

[MabezDev]

Sorry I thought I attached it, my bad!

core-3704b16aa5ea1124.s

[MabezDev]

I have just built Rust's libcore for xtensa! I needed to pass -C debuginfo=0 flag to the compiler to omit the frame pointer (from https://www.reddit.com/r/rust/comments/5vir9j/unnecessary_stack_adjustments/de2h9lt/)

I am yet to verify the produced binary's are valid but it's progress.

Thanks for your help, please feel free to close this now.

[igrr]

Pretty interested how your porting effort goes! Please open an issue if you find any other problem.