Обсуждение 2.1.0 Beta c --enable-cxx-flags

[Sermus]

CHERTS, провел несколько экспериментов с попыткой сборки вот этого

extern "C" void user_init(void)
{
    stringstream ss;
    string str;
    str += "test";
    ss << str;
}

Сначала попробовал собрать с libc. Оно бы собралось, но не влазит в IRAM, потому что вытягивает в IRAM много чего из libc.

Сделал из Вашего libc libcirom (кстати, почему бы Вам не включить сборку libcirom в UDK?) и попытался слинковать с ним. Получил портянку ошибок вроде

Спойлер: Ошибки

c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/5.2.0/../../../../xtensa-lx106-elf/lib\libstdc++.a(cp-demangle.o): In function `d_identifier':
d:\Neo\crosstool\dl\gcc-5.2.0\build-2\xtensa-lx106-elf\libstdc++-v3\libsupc++/cp-demangle.c:1681.text+0x425): dangerous relocation: call0: call target out of range: memcmp
c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/5.2.0/../../../../xtensa-lx106-elf/lib\libstdc++.a(cp-demangle.o): In function `d_growable_string_resize':
d:\Neo\crosstool\dl\gcc-5.2.0\build-2\xtensa-lx106-elf\libstdc++-v3\libsupc++/cp-demangle.c:3774.text+0x7f6): dangerous relocation: call0: call target out of range: realloc
d:\Neo\crosstool\dl\gcc-5.2.0\build-2\xtensa-lx106-elf\libstdc++-v3\libsupc++/cp-demangle.c:3777.text+0x801): dangerous relocation: call0: call target out of range: free

Такое чувство, что libstdc++ собран без -mlongcalls?

 

[pvvx]

С версией 2.1 все прошлые большие проекты транслируются без проблем и какой либо замены чего в makefile или опциях Eclipse. "Оптимизация" - "патчи" дали до 10 байт уменьшения размера на разных проектах. Ранее то-же самое и более достигалось путем распаковки всех либ на объектники и линковки общей гурьбой - линковщику видимо легче собрать... Это происходило и если транслировать не через makefile, а через Internal Builder в Eclipse.

 

[CHERTS]

вот получился список ошибок примеров версии 2.1

Блин, вы бы хоть указали для каких примеров идут такие ошибки, а то трехметровая портянка ошибок, от чего она - непонятно

примеры esp_mesh_sdk_app_* - скорее всего будут удалены из UDK как и ESP8266_MESH_SDK, т.к. Espressif убрала mesh_sdk c github и что с ней дальше будет непонятно.

пример esp8266_ili9341 собирается без ошибок, что за eps8266_ili9341 у вас с ошибками я не знаю.
все примеры i2c_* собираются тоже без ошибок, что за ошибки у вас я не пойму.

пример nodemcu-firmware - тоже собирается без ошибок

Вы уверены в том, что ESP32 будет востребован?

Не уверен, но конкуренты не спят, в плане наколхозить компилятор под cygwin.

Когда ожидается gdb?

В финальном 2.1 думаю будет, сейчас я выложил gcc 5.2 без gdb, была цель его собрать и проверить в работе, следующий шаг - это собрать gdb с ним, на этой неделе уделю все внимание сборке gdb.

И поподробнее можно про дополнения в gcc - это оптимизация переменных в IRAM, FLASH или ?

Поподробнее это тут
Засада была в том, что jcmvbkbc больше не ведет отдельно репо с gcc-xtensa-lx106, и все новые патчи сразу идут в crosstool-NG, а сrosstool-NG под win c mingw не собрать без танцев с бубном, поэтому я написал скрипт сборки gcc-xtensa-lx106 из оригинального gcc 5.2 + выудил все необходимые патчи для gcc,binutils ,newlib,gdb из сrosstool-NG, см. каталог patches в моем репо.

Не подскажите как с switch(x) сделать, чтобы таблица переходов помешалась не в RAM

Увы, не знаю

CHERTS, провел несколько экспериментов с попыткой сборки вот этого

А это вот ЭТО собирается на UDK 2.0.9 ? Можно полный пример для эксперимента?
Если я правильно собрал GCC, то опции -mlongcalls -mtext-section-literals присутствуют, может я конечно неправильно опции в configure, я сделал так ../configure ... --enable-cxx-flags='-mlongcalls -mtext-section-literals' при сборке gcc, а может нужно было так ../configure ... -mlongcalls -mtext-section-literals, но вроде как в патчах jcmvbkbc было с --enable-cxx-flags=

Using built-in specs.
COLLECT_GCC=xtensa-lx106-elf-gcc.exe
COLLECT_LTO_WRAPPER=c:/espressif/xtensa-lx106-elf/bin/../libexec/gcc/xtensa-lx106-elf/5.2.0/lto-wrapper.exe
Target: xtensa-lx106-elf
Configured with: ../configure --prefix=/d/Neo/crosstool/xtensa-lx106-elf --target=xtensa-lx106-elf --enable-multilib --disable-nls --disable-shared --disable-threads --with-gnu-as --with-gnu-ld --with-gmp=/d/Neo/crosstool/build/gmp --with-mpfr=/d/Neo/crosstool/build/mpfr --with-mpc=/d/Neo/crosstool/build/mpc --enable-languages=c,c++ --with-newlib --disable-libssp --disable-__cxa_atexit --enable-decimal-float=yes --enable-cxx-flags='-mlongcalls -mtext-section-literals'
Thread model: single
gcc version 5.2.0 (GCC)

 

[Sermus]

А это вот ЭТО собирается на UDK 2.0.9 ? Можно полный пример для эксперимента?

Это не собиралось на 2.0.9 потому что не должно было. Фиксы от Макса как раз и нужны для того, чтобы оно начало собираться. Поэтому вопрос не имеет особого смысла. По поводу полного примера - отправил в личку.

 

[Sermus]

И еще хочу напомнить вопрос про libcirom. Добавить его генерацию по затратам - почти ноль, а вот польза весьма пользительна.
На всякий случай, получается из libc вот так:
xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text --rename-section .literal=.irom0.literal libc.a libcirom.a

 

[Sermus]

Это не собиралось на 2.0.9 потому что не должно было. Фиксы от Макса как раз и нужны для того, чтобы оно начало собираться. Поэтому вопрос не имеет особого смысла. По поводу полного примера - отправил в личку.

Проверил, не собирается и в open sdk с фиксами. Так что задал вопрос jcmvbkbc.

 

[CHERTS]

Проверил, не собирается и в open sdk с фиксами. Так что задал вопрос jcmvbkbc.

На linux с open sdk gcc собран с теми же --enable-cxx-flags='-mlongcalls -mtext-section-literals' что и у меня, так что дело в патчах, то есть да, нужна помощь jcmvbkbc

 

[jcmvbkbc]

Засада была в том, что jcmvbkbc больше не ведет отдельно репо с gcc-xtensa-lx106, и все новые патчи сразу идут в crosstool-NG, а сrosstool-NG под win c mingw не собрать без танцев с бубном, поэтому я написал скрипт сборки gcc-xtensa-lx106 из оригинального gcc 5.2 + выудил все необходимые патчи для gcc,binutils ,newlib,gdb из сrosstool-NG, см. каталог patches в моем репо.

Не то что "не веду", фиксов для gcc довольно давно не было. Если будет что-то, что есть смысл затащить в ветки call0-4.8.2/call0-4.9.2/lx106-5.1 GitHub - jcmvbkbc/gcc-xtensa: gcc for xtensa -- будут коммиты.
С другой стороны, сборку я всё равно тестирую в crosstool-NG, патчи для binutils и gdb тоже собраны там, так что наверно имеет смысл тянуть патчи оттуда.

 

[CHERTS]

С другой стороны, сборку я всё равно тестирую в crosstool-NG, патчи для binutils и gdb тоже собраны там, так что наверно имеет смысл тянуть патчи оттуда.

Для gcc-5.2, binutils, gdb я как раз все патчи из crosstool-NG тяну. gcc 5.2 собирается и работает, правда с --enable-cxx-flags='-mlongcalls -mtext-section-literals' есть проблемы, Sermus чуть выше об этом написал.

И еще мне не удалось собрать gdb 7.10 как раз с патчами из crosstool-NG, думаю дело в mingw, вылазит такая ошибка:

make[8]: Entering directory `/d/Neo/crosstool/dl/gdb-7.10/build/gdb/build-gnulib
/import'
gcc -DHAVE_CONFIG_H -I. -I../../../../gdb/gnulib/import -I..     -g -O2 -D__USE_
MINGW_ACCESS -MT rename.o -MD -MP -MF .deps/rename.Tpo -c -o rename.o ../../../.
./gdb/gnulib/import/rename.c
In file included from ./sys/stat.h:44:0,
                 from ../../../../gdb/gnulib/import/rename.c:34:
c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct rpl_timespec'

struct timespec
        ^
./time.h:386:8: note: originally defined here
struct timespec
        ^
make[8]: *** [rename.o] Error 1
make[8]: Leaving directory `/d/Neo/crosstool/dl/gdb-7.10/build/gdb/build-gnulib/
import'

 

[jcmvbkbc]

И еще мне не удалось собрать gdb 7.10 как раз с патчами из crosstool-NG, думаю дело в mingw, вылазит такая ошибка:

c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct rpl_timespec'

Может быть это поможет: Re: Gnulib's time.h and the latest MinGW32 runtime ?