need -mlongcalls option for compiling libstdc++

[balazsracz]

Hi,

When trying to use libstdc++ for pretty much anything (e.g. instantiate an std::string object), we run into call0 relocation errors:

/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/lib/libstdc++.a(string-inst.o): In function std::char_traits<char>::copy(char*, char const*, unsigned int)': /opt/esp/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/build/build-cc-final/xtensa-lx106-elf/libstdc++-v3/include/bits/basic_string.tcc:230:(.text._ZNSs7_M_copyEPcPKcj[std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_copy(char*, char const*, unsigned int)]+0x11): dangerous relocation: call0: call target out of range: memcpy /opt/esp/esp-open-sdk/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/lib/libstdc++.a(string-inst.o): In functionstd::char_traits::move(char_, char const_, unsigned int)':
/opt/esp/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/build/build-cc-final/xtensa-lx106-elf/libstdc++-v3/include/bits/basic_string.tcc:230:(.text.ZNSs7_M_moveEPcPKcj[std::basic_string<char, std::char_traits, std::allocator >::M_move(char, char const, unsigned int)]+0x11): dangerous relocation: call0: call target out of range: memmove

It seems that the libstdc++ library that the crosstool-NG builds is compiled without the -mlongcalls option. Since the default linker scripts define the libc functions like memcpy memmove etc to be versions in the built-in ROM, they are by the memory map more than 512KB away from both the .iram_seg as well as the .irom_seg memory region.

This means that the libstdc++ does not link when placed into iram and also does not link when placed into the irom.

The workaround is to recompile it with -mlongcalls or stop using the ROM builtins for C library functions. Both of these require various levels and intrusiveness of patches.

It would be nice if the libstdc++ (and maybe other libraries too?) would be compiled with -mlongcalls from the start and then the users would not need to patch after the fact.

thanks,
Balazs

[jcmvbkbc]

Please see this pull request: #146