New fork testing

[MabezDev]

Espressif has just released there new iteration of the fork, its not quite working for Rust as is because of this issue. However, I have forked and made the required changes to get it working here. #19 is the branch with changes required in this fork.

@bjoernQ @pacmancoder @rodrigorc if you'd like to try it out and see if it solves any of your issues.

@lexxvir this may mean you can remove some of your work arounds in you projects :)

[rodrigorc]

I've just compiled this branch, and indeed it solves my issue with Arc and atomics.
It also seems to fix that other bug that forced me to add --emit llvm-bc to the rustflags.

The only weird think is that I had to add -DLLVM_CXX_STD=c++14 to cmake when building clang or it would not compile. Something to do with std::make_unique. Maybe it should be the default?

Thank you so much for your awesome work!

[lexxvir]

Hi @MabezDev,

Thank you for all work you've done!

I successfully built LLVM & Rust from your branches (llvm9-rust). Now I can remove "--emit", "llvm-bc,link" from .cargo/config.
On my shallow testing all works!

Now we on one step near to integrate Xtensa arch into upstream! 🎉

[MabezDev]

@rodrigorc

The only weird think is that I had to add -DLLVM_CXX_STD=c++14 to cmake when building clang or it would not compile. Something to do with std::make_unique.

Ah so this is something I forgot to port when rebasing the patchset to 9.0.1, as I don't compile clang I didn't notice. I expect this will work properly when the espressif guys rebase the fork properly instead of my dodgy attempt 😂

@lexxvir Glad it seems to be working, let me know if you run into any issues.

FYI I released a short blog on the progress on using Rust on the esp32: https://mabez.dev/blog/posts/esp32-rust-svd-pac/ I know most of you are using the idf but there might be some useful info in there :)

[pacmancoder]

@MabezDev thanks for your great work! Sadly, I won't have much time for testing in the near few weeks, but I will certainly try it out as soon as possible and leave updates under the tickets.

[reitermarkus]

In the previous version of the fork I had noticed a weird bug in std::net::ToSocketAddrs which I tracked down to somewhere inside of Option::take but couldn't fix it or reproduce it outside of my sample project. This seems to be fixed now.

There is however a regression regarding std::net::ToSocketAddrs, which can easily be reproduced with the following:

std::net::ToSocketAddrs::to_socket_addrs("0.0.0.0:80");

This produces the following compile error:

LLVM ERROR: Error while trying to spill A8 from class AR: Cannot scavenge register without an emergency spill slot!

I can work around this for now by using SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), 80) instead.

[MabezDev]

Thanks for testing @reitermarkus. Would you mind reporting the issue on the llvm fork?

Edit: It's also entirely possible the abi impl for xtensa inside Rust is wrong. See #18

[reitermarkus]

Reported it here: espressif/llvm-project#13

[MabezDev]

Hi all, the new fork is now the default in xtensa-target, the quickstart instructions has been updated too. Thanks for testing guys!