Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xtensa Support #5467

Open
Tracked by #13
schroffl opened this issue May 29, 2020 · 34 comments
Open
Tracked by #13

Xtensa Support #5467

schroffl opened this issue May 29, 2020 · 34 comments
Labels
arch-xtensa Tensilica Xtensa backend-llvm The LLVM backend outputs an LLVM IR Module. standard library This issue involves writing Zig code for the standard library. upstream An issue with a third party project that Zig uses.
Milestone

Comments

@schroffl
Copy link
Contributor

schroffl commented May 29, 2020

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
Copy link

frett27 commented May 29, 2020

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
Copy link
Contributor Author

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

@pixelherodev
Copy link
Contributor

Yes, exactly.

@pixelherodev
Copy link
Contributor

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
Copy link
Contributor Author

schroffl commented Jun 1, 2020

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
Copy link

frett27 commented Jun 11, 2020

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) espressif/llvm-project#18

@Vexu Vexu added stage1 The process of building from source via WebAssembly and the C backend. standard library This issue involves writing Zig code for the standard library. upstream An issue with a third party project that Zig uses. labels Aug 1, 2020
@Vexu Vexu added this to the 0.8.0 milestone Aug 1, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@creationix
Copy link

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
Copy link
Contributor

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!) espressif/llvm-project#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
Copy link
Contributor

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
Copy link
Contributor

daurnimator commented Dec 7, 2020

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

@creationix
Copy link

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
Copy link

inetbowser commented Jan 23, 2021

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
Copy link

pyrossh commented Jan 23, 2021

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

@frett27
Copy link

frett27 commented Mar 6, 2021

awesome !

@kassane
Copy link
Contributor

kassane commented Mar 17, 2021

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: 🆗
zig-host build: 🆗
llvm-musl build: 🆗
zig-musl build: ❌


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
Copy link

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

@kassane
Copy link
Contributor

kassane commented Mar 24, 2021

@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.

@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
@weitzj
Copy link

weitzj commented Sep 12, 2021

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

@kassane
Copy link
Contributor

kassane commented Dec 22, 2021

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

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

@ominitay
Copy link
Contributor

Ooooop I didn't spot this
Hopefully nothing??

@ominitay
Copy link
Contributor

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
Copy link

Any news on this?

@bracki
Copy link

bracki commented Aug 27, 2022

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

@kassane
Copy link
Contributor

kassane commented Aug 28, 2022

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.

@Vexu Vexu removed the stage1 The process of building from source via WebAssembly and the C backend. label Dec 7, 2022
@weitzj
Copy link

weitzj commented Mar 12, 2023

Looks like llvm 16 will have xtensa support:

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

@weitzjdevk
Copy link

weitzjdevk commented Mar 18, 2023

@kassane
Copy link
Contributor

kassane commented Mar 19, 2023

@weitzj ,
Try following the LLVM16 branch:
0ca3582

@andrewrk andrewrk modified the milestones: 0.13.0, 0.11.0 Mar 19, 2023
@jaedson-barbosa
Copy link

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
Copy link
Member

andrewrk commented Apr 9, 2023

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.

@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@kassane
Copy link
Contributor

kassane commented Feb 18, 2024

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

@aykevl
Copy link

aykevl commented Apr 25, 2024

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: espressif/llvm-project#53

@Borderliner
Copy link

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

@alexrp
Copy link
Member

alexrp commented Sep 5, 2024

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.

@alexrp alexrp added arch-xtensa Tensilica Xtensa backend-llvm The LLVM backend outputs an LLVM IR Module. zig cc Zig as a drop-in C compiler feature and removed os-xtensa zig cc Zig as a drop-in C compiler feature labels Oct 3, 2024
@newcomertv
Copy link

You wouldn't run linux on an esp32 (Xtensa).
I believe there have been a few crazies that did it but its not really usable.

I somehow ended up on this zig issue so please note I have not written a single line of zig in my life but I've worked with esp32s (among other MCUs) and have dealt with portability issues for some time now:

The best bet is to allow for various "std" targets as different projects run on different os's.

Until now all my esp projects have been using esp-idf with FreeRTOS. Here is an example of how rust does some bindings to that: https://github.com/esp-rs/esp-idf-hal

Zephyr is more cross platform though very niche on something like the esp32. ( yet to meet someone that actually did that in a professional environment )

In general most embedded code isn't very portable since the OS keeps on changing and you need to access hardware which won't be the same.
You can check out the embedded-hal, embassy and rtic projects to see how rust attempts to deal with this problem.

Maybe there'll be some cross pollination happening?

Note: Please try to think of timeouts and fallible operations from the get go. MCUs don't care about large numbers crunching or doing stuff as fast as possible. They care about doing it reliably and predictably.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-xtensa Tensilica Xtensa backend-llvm The LLVM backend outputs an LLVM IR Module. standard library This issue involves writing Zig code for the standard library. upstream An issue with a third party project that Zig uses.
Projects
None yet
Development

No branches or pull requests