Update to 1.39.0

[fmckeogh]

Xtensa-specific commits were cherry-picked on top of the rust-lang/rust 1.39.0 tag.

[fmckeogh]

Oh wait, hold on, I need to remove myself as the author.

[MabezDev]

Thanks, this builds on my system, but I can't build the xtensa-quickstart blinky program, though I might have messed something up with the linker script in that project. I'll take a look asap.

cc: @lexxvir (and @bjoernQ, if you've sorted your windows issues :)) would you mind testing with your projects again?

[lexxvir]

I have tested this branch on my project.

My project (workspace) have ~ 40 examples and 4 binaries. All examples compiled successfully, but one of the 4 binaries failed on linking phase with following error:
reader.c0oriqys-cgu.0:(.text._ZN4core4iter6traits10exact_size17ExactSizeIterator8is_empty17h65f62fc3b1930bf5E+0x82): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.literal.literal+0x156c)

It is main binary of the project, so it used most of functionality of all crates and it have most big size.
Linking failed with long list of such errors, all have the same text except the place where error occurs (not only in libcore).

I have no idea what cause the error. I did some investigation by "detach" some parts of the code and see if error pop up. I have not found particular cause but it looks like adding some generic code leads to this error.

I'll try to investigate it again a bit lately.

[MabezDev]

Thanks @lexxvir, I've encountered similarly weird linker errors. I hope to explore more this weekend.

[bjoernQ]

I tried it on OSX and something very minimal compiled fine so far but I currently don't have something more complex to test.

When I use a custom allocator I get an error during linking about dangerous relocation but I also got that with 1.37

[lexxvir]

Hi guys,

I have dived into these errors a bit and found following topic: https://esp32.com/viewtopic.php?f=2&t=11859&start=10#p47729

I have tried to pass -mtext-section-literals to the linker, but then linker fails with Error: literal pool location required for text-section-literals; specify with .literal_position. It seems LLVM should be able generate .literal_position in the ASM, but it have not such feature.

Also I have tried to place .literal section along side .textsection using IDF ld scripts, but without success.

[lexxvir]

Hi again,

As it often happens I found solution just after 5 minutes when I did previous comment 😃
It is --auto-litpools option. It is GCC assembler option, so to pass it through the linker it should be written as -Wa,--auto-litpools.

Here is my linker.sh script that I use instead of xtensa-esp32-elf-gcc:

#!/bin/bash

cmdline="xtensa-esp32-elf-gcc -mlongcalls -Wa,--auto-litpools"

for OPT in $@;
do
	case "$OPT" in
		*libcompiler_builtins-*.rlib*) ;; # cut off complier_builtins
		*) cmdline+=" $OPT" ;;
	esac
done

#echo $cmdline > options.txt
$cmdline

I did some real world tests with my application and it seems it works!
But I noticed that binary size increased by 7%.

[MabezDev]

Awesome @lexxvir ! Looks like this is ready to merge, @Chocol4te would you mind fixing the merge conflicts?

[fmckeogh]

😬 Since I cherry-picked all the new commits from this fork onto the 1.39.0 tag, this branch will need to overwrite this fork's history, otherwise we would still have a mixture of upstream and xtensa commits. It will leave the fork up to date with 1.39.0, with all the xtensa commits on top making future rebases and the eventual upstream merge straightforward.

[pacmancoder]

@lexxvir @MabezDev still getting the problem with "dangerous relocation l32r" when compiling rust library and linking it to the main idf esp8266 project.

Tried to overcome this issue by proposed linker script, by adding -C link-args="-mlongcalls -Wa,--auto-lit-pools" and adding the same args to the link args for IDF CMake file, but still no luck.

This issue kicks in when I trying to construct alloc::String with a string literal (let s = String::from("some literal") while using custom GlobalAllocator.

Error output:

../../target/xtensa-esp8266-none-elf/release/libfirmware.a(firmware-5b7e9638ff0ed6ee.2qffuh8m3mnmhmu5.rcgu.o): In function `__rust_alloc':
2qffuh8m3mnmhmu5:(.text.__rust_alloc+0xb): dangerous relocation: l32r: literal target out of range (try using text-section-literals): .literal
../../target/xtensa-esp8266-none-elf/release/libfirmware.a(firmware-5b7e9638ff0ed6ee.2qffuh8m3mnmhmu5.rcgu.o): In function `__rust_dealloc':
2qffuh8m3mnmhmu5:(.text.__rust_dealloc+0xd): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.literal+0x4)
../../target/xtensa-esp8266-none-elf/release/libfirmware.a(firmware-5b7e9638ff0ed6ee.2qffuh8m3mnmhmu5.rcgu.o): In function `__rust_realloc':
2qffuh8m3mnmhmu5:(.text.__rust_realloc+0xf): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.literal+0x8)
collect2: error: ld returned 1 exit status

UPD: issue reproduces on any dynamic allocation attempt
UPD: found ugly solution, moved to the ticket #16