Xtensa Support

[schroffl]

Hi guys,

is it currently possible to compile Zig for the ESP8266/ESP32? According to this forum post it seems like LLVM supports it as a target. I would love to help with this feat, but I'm not really sure where to start. The most helpful thing I could find is this fork.

If someone could provide me a little kickstart from which I can dive into this matter I would be very thankful :)

[frett27]

Currently zig is compiled against LLVM10 that is not yet supported for extensa. Compiling extensa extension against LLVM10 is not straight forward yet as it is not in the main stream. You have a boostrap for compiling zig, with llvm here, it might help if you want to have a deep dive on it : https://github.com/ziglang/zig-bootstrap

[schroffl]

So I have to install an LLVM-Version with extensa-support and then build zig with that?

[pixelherodev]

Yes, exactly.

[pixelherodev]

Actually, there's more work you would need to get XTensa even to what we would consider a tier IV target: you'd probably need to teach Zig's stage1 compiler how to tell LLVM to target XTensa.

[schroffl]

I noticed that I accidentally entered an invalid URL for the forum post. If any of you want to have a look – it's fixed now.

[frett27]

Seems expressif is near to release the expressif llvm10 , so it will be compatible (with the pixeldev modifications to do on architecture declaration in zig) https://github.com/espressif/llvm-project/issues/18

[creationix]

I see this is now part of the 0.8.0 milestone, but that's not due for release till next summer. Looking upstream at the expresif repo it appears they have merged in the bits. Would it be possible for me to build their llvm from source and then bootstrap zig using that or are there still major parts missing?

[daurnimator]

Looking upstream at the expresif repo it appears they have merged in the bits.

Indeed it looks like just 7 days ago they published their LLVM 11 branch (hooray!) https://github.com/espressif/llvm-project/pull/42

For zig itself to rely on it, we would it to be merged into upstream LLVM. However:

Would it be possible for me to build their llvm from source and then bootstrap zig using that or are there still major parts missing?

you could definitely start work now on zig support for xtensa on top of their LLVM fork.

[FireFox317]

What about the linker? I don't think these patches include patches for the linker right? So you would still have to use the GCC linker that Xtensa provides :(

[daurnimator]

What about the linker? I don't think these patches include patches for the linker right? So you would still have to use the GCC linker that Xtensa provides :(

I believe that is true. To start with you can get zig build-obj working though. I believe a few people have made progress here before

• @INetBowser ?
• https://github.com/Schroedingers-Hat/xtensa-zig
• @SuperAuguste ?

[creationix]

Thanks. I'm afraid this is still a bit too involved than I'm able to work with at the moment. I'm glad it's getting closer though!

I'm really excited for the day I can write esp32 firmware using zig.

[inetbowser]

Hi, Sry for the late response, didn't see I was mentioned here :D I managed to get Zig working for ESP32/ESP8266. Though the Xtensa backend still has some minor problems (see here).

[pyrossh]

Nice will see if I can get some zig code to display something on my m5stack core.

[frett27]

awesome !

[kassane]

Hi, Sry for the late response, didn't see I was mentioned here :D I managed to get Zig working for ESP32/ESP8266. Though the Xtensa backend still has some minor problems (see here).

I try compile on my machine, and made some readjustments in the build file of the zig-bootstrap repo especially for this project, but after compiling everything right at the end this problem occurs and I didn't know that still had this additional parameter. run: build x86_64-linux-musl

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LLVM_LLVMXTENSAUTILS_LIB
    linked by target "zigcpp" in directory /home/kassane/Downloads/Code/xtensa-bootstrap/zig

status

llvm-host build: :ok: zig-host build: :ok: llvm-musl build: :ok: zig-musl build: :x:

---

Tests (zig-host)

So today when I tried some tests with zig-host and couldn't generate the object file due to the lld error, but after adding the parameter -fno-LLVM then the object is generated, however xtensa-esp32-elf-gcc doesn't recognize the file structure.

Note: both tests are simple main function!

$> zig build-obj test.zig -target xtensa-freestanding -mcpu esp32 # error
...
$> zig build-obj test.zig -target xtensa-freestanding -mcpu esp32 -fno-LLVM # object generated
...
$> xtensa-esp32-elf-gcc test.o --verbose

Output:

Using built-in specs.
COLLECT_GCC=xtensa-esp32-elf-gcc
COLLECT_LTO_WRAPPER=/home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/lto-wrapper
Target: xtensa-esp32-elf
Configured with: /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf --prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf --exec_prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf --with-local-prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf --with-headers=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.24.0.302_32e30a1' --disable-__cxa_atexit --enable-cxx-flags=-ffunction-sections --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpfr=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpc=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-isl=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --enable-lto --enable-target-optspace --without-long-double-128 --disable-nls --enable-multiarch --enable-languages=c,c++ --disable-libstdcxx-verbose --enable-threads=posix --enable-gcov-custom-rtio --enable-libstdcxx-time=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (crosstool-NG 1.24.0.302_32e30a1) 
COMPILER_PATH=/home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/:/home/kassane/.local/bin/../libexec/gcc/:/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/bin/
LIBRARY_PATH=/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/:/home/kassane/.local/bin/../lib/gcc/:/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib/
COLLECT_GCC_OPTIONS='-v'
 /home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/collect2 -plugin /home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/liblto_plugin.so -plugin-opt=/home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc847BiG.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lnosys -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib/crt0.o /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crti.o /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crtbegin.o -L/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0 -L/home/kassane/.local/bin/../lib/gcc -L/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib test.o -lgcc -lc -lnosys -lc -lgcc /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crtend.o /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crtn.o
/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib/crt0.o:(.literal+0x0): undefined reference to `main'
/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/bin/ld: final link failed: file truncated
collect2: error: ld returned 1 exit status

zig cc

$> zig cc -c test.c -target xtensa-freestanding -mcpu esp32 # crash compiler
...
$> zig cc -emit-llvm test.c -target xtensa-freestanding -mcpu esp32 # linker error
# output:
ld.lld: error: /home/kassane/.cache/zig/o/a3ec2f7e1c524519e2519734f1740cc5/test.o: could not infer e_machine from bitcode target triple xtensa-unknown-unknown-eabi

[inetbowser]

@kassane did you already try to build zig with these steps? With the zig built with these steps everything works like expected.

[kassane]

@INetBowser, yep

I used all the parameters to compile the LLVM (-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="Xtensa"). I used the Bootstrap build file as a reference, but following xtensa.md step by step.

[weitzj]

Do you have a goal in mind how this relates to the free standing compiler without LLVM?

[kassane]

More alternative: https://github.com/ominitay/zig/tree/xtensa

@ominitay, what is the difference of this proposal compared to others?

[ominitay]

Ooooop I didn't spot this Hopefully nothing??

[ominitay]

So running a git diff, there are a couple slight things missing from theirs that are included in mine, but they should be functionally the same.

[jaedson-barbosa]

Any news on this?

[bracki]

What does it take to get one of the PRs merged?

[kassane]

Both PRs are outdated and in this one as it is an unofficial architecture of LLVM it doesn't make much sense to use it. Unless they make their own support solution.

[weitzj]

Looks like llvm 16 will have xtensa support:

• https://github.com/espressif/llvm-project/issues/4#issuecomment-1368203827
• https://www.phoronix.com/news/LLVM-Xtensa-Backend
• https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/Xtensa

So now one would have to bootstrap Zig with llvm 16 ? Is that correct?

[weitzjdevk]

Llvm 16 got released https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.0

[kassane]

@weitzj , Try following the LLVM16 branch: https://github.com/ziglang/zig/commit/0ca3582a86da377a25ea144acf94531dd8a28722

[jaedson-barbosa]

Hi, is there any way for me to collaborate on this support addition? Is there an issue logging everything that still needs to be done?

[andrewrk]

Zig master branch now depends on LLVM 16, which has experimental Xtensa support. This means it is disabled by default. In order to play with Xtensa and Zig together, you need to build LLVM from source using -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Xtensa and build Zig with -Dllvm_has_xtensa.

[kassane]

This means it is disabled by default. In order to play with Xtensa and Zig together, you need to build LLVM from source using -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Xtensa and build Zig with -Dllvm_has_xtensa.

Missing add on build.zig llvm_libs:

    "LLVMXtensaAsmParser",
    "LLVMXtensaDesc",
    "LLVMXtensaInfo",
    "LLVMXtensaCodeGen",
    "LLVMXtensaDisassembler",

Fixing linking undefined references.

-Dllvm_has_xtensa (old flag)

Currenty (v0.12.0-dev), -Dllvm-has-xtensa

Reference

• https://github.com/ziglang/zig/compare/master...kassane:zig:xtensa (need espressif fork) v0.12.0-dev

[aykevl]

What about the linker? I don't think these patches include patches for the linker right? So you would still have to use the GCC linker that Xtensa provides :(

@FireFox317 I implemented linker support a while ago: https://github.com/espressif/llvm-project/pull/53

[Borderliner]

I'd love to see a more straightforward approach to compiling a zig app for my ESP32

[alexrp]

The main issue here is that LLVM's Xtensa target is experimental. To my knowledge, historically, experimental targets have not been enabled in released Zig binaries. So this is really just a question of when Xtensa graduates to being a supported target in LLVM. I don't imagine it'll take terribly long since Espressif are actively submitting patches.

That aside, I have a question: Is running Linux on these actually a thing that people do? (I know the kernel has support for Xtensa, but I don't know if it's commonly used vs bare metal.) If yes, I can prioritize adding minimal standard library support for that - namely startup code and std.os.linux arch bits.