ESP8266 Community Forum

- Fri Feb 05, 2016 7:25 pm #40533

That's very good to hear. It would be awesome.
Would you be kind enough to notify this topic whenever this is enabled?
I'll go and watch the crosstool-NG repo from time to time but I'm afraid I'll miss it

Ok, I've pushed the fix to https://github.com/jcmvbkbc/crosstool-N ... nsa-1.22.x . Now libstdc++ should be build with -mlongcalls -mtext-section-literals, which should fix short range of call0.
Please try (you'd need to rebuild crosstool-ng, clean up .build directory and old .config, reconfigure for xtensa-lx106-elf and rebuild).

- Sat Feb 06, 2016 11:28 am #40569

Ok, I've pushed the fix to https://github.com/jcmvbkbc/crosstool-N ... nsa-1.22.x . Now libstdc++ should be build with -mlongcalls -mtext-section-literals, which should fix short range of call0.
Please try (you'd need to rebuild crosstool-ng, clean up .build directory and old .config, reconfigure for xtensa-lx106-elf and rebuild).

Thank you jcmvbkbc. I got a fresh clone from the crosstool-NG repo and built a new toolchain. I struggled a bit with the config setup as I usually compile the toolchain from the esp-open-sdk (which provides a config for crosstool-NG).
Unfortunately I still get dreaded "dangerous relocation: call0".
Here are some of them (I have many more of course):

Code: Select all/Volumes/esp-open-sdk/crosstool-NG-lc/x-tools/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libstdc++.a(cp-demangle.o): In function `d_append_string':
/Volumes/esp-open-sdk/crosstool-NG-lc/.build/xtensa-lx106-elf/build/build-cc-gcc-final/xtensa-lx106-elf/libstdc++-v3/libsupc++/cp-demangle.c:3732:(.text+0x3c5): dangerous relocation: call0: call target out of range: strlen
/Volumes/esp-open-sdk/crosstool-NG-lc/x-tools/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libstdc++.a(cp-demangle.o): In function `d_append_num':
/Volumes/esp-open-sdk/crosstool-NG-lc/.build/xtensa-lx106-elf/build/build-cc-gcc-final/xtensa-lx106-elf/libstdc++-v3/libsupc++/cp-demangle.c:3739:(.text+0x3ee): dangerous relocation: call0: call target out of range: sprintf
/Volumes/esp-open-sdk/crosstool-NG-lc/x-tools/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libstdc++.a(cp-demangle.o): In function `d_identifier':
/Volumes/esp-open-sdk/crosstool-NG-lc/.build/xtensa-lx106-elf/build/build-cc-gcc-final/xtensa-lx106-elf/libstdc++-v3/libsupc++/cp-demangle.c:1617:(.text+0x56e): dangerous relocation: call0: call target out of range: memcmp
/Volumes/esp-open-sdk/crosstool-NG-lc/x-tools/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libstdc++.a(cp-demangle.o): In function `d_growable_string_resize':
/Volumes/esp-open-sdk/crosstool-NG-lc/.build/xtensa-lx106-elf/build/build-cc-gcc-final/xtensa-lx106-elf/libstdc++-v3/libsupc++/cp-demangle.c:3620:(.text+0x752): dangerous relocation: call0: call target out of range: realloc
/Volumes/esp-open-sdk/crosstool-NG-lc/.build/xtensa-lx106-elf/build/build-cc-gcc-final/xtensa-lx106-elf/libstdc++-v3/libsupc++/cp-demangle.c:3623:(.text+0x75b): dangerous relocation: call0: call target out of range: free


That being said, it is quite possible my config is wrong (see attached). For the record I had to compile for gcc-4.8.5 as compiling with gcc-5.2 would create errors. I am not sure where the -mlongcalls and -mtext-section-literals should be reflected in the crosstool-NG toolchain Makefiles.
I did a

Code: Select allgrep -R mlongcalls *


in the crosstool-NG/.build/src/gcc-4.8.5/libstdc++-v3 which caught nothing.
Should I be adding custom arguments the ct-ng config file?

JU

You do not have the required permissions to view the files attached to this post.

- Sat Feb 06, 2016 12:42 pm #40572

That being said, it is quite possible my config is wrong (see attached).

Yes.

For the record I had to compile for gcc-4.8.5 as compiling with gcc-5.2 would create errors.

My updates don't change the default gcc version to 5.x, it's still 4.8.x

I am not sure where the -mlongcalls and -mtext-section-literals should be reflected in the crosstool-NG toolchain Makefiles.

They're in the samples/xtensa-lx106-elf/crosstool.config and they are copied to .config at the configuration step (ct-ng xtensa-lx106-elf).

To update the open-esp-sdk I did the following in its root directory:

Code: Select allmake clean
sed -i .gitmodules -e 's/branch = lx106-g++/branch = xtensa-1.22.x/'
git submodule update --remote crosstool-NG
make STANDALONE=y

Then in the process of build CT_CC_GCC_ENABLE_CXX_FLAGS="-mlongcalls -mtext-section-literals" appeared in the crosstool-NG/.config.

- Sat Feb 06, 2016 7:53 pm #40592

To update the open-esp-sdk I did the following in its root directory:

Code: Select allmake clean
sed -i .gitmodules -e 's/branch = lx106-g++/branch = xtensa-1.22.x/'
git submodule update --remote crosstool-NG
make STANDALONE=y

Then in the process of build CT_CC_GCC_ENABLE_CXX_FLAGS="-mlongcalls -mtext-section-literals" appeared in the crosstool-NG/.config.

Success! I got it working. Thanks a lot for the great work jcmvbkbc!
I had to jump through a few more hoops though. libstdc++ is dragging quite a few symbols from libgcc which I had to keep in iram (for the aforementioned reasons) at least partially and it did explode the iram. I got around this by moving some object files from libgcc to irom by editing my linker script.

A few reflections:

• It still eludes me why some of libgcc needs to stay in iram. It's unfortunate since it consumes quite a lot of ram. Obviously I can cherry pick some object files from the library and move them to irom until it breaks, but it's far from ideal. The fact that the ESP crashes even before getting to user_init makes this issue hard to debug.
• __udivsi3 (which is the cause of my headaches but may not be the only one) and a few other libgcc symbols are actually provided by the rom. Is it an option to strip them from libgcc at link time or maybe one needs to edit them away from the source code of the toolchain?