Существует ли с++ среда для esp8266?

[Sermus]

Нет, не помогли и эти стабы.
Подумал еще, вдруг в esp-open-sdk какая грязь после предыдущей сборки осталась. Сделал чистый clone, переключил crosstool-ng на xtensa-1.22.x (по умолчанию он смотрит на lx106). Поправил makefile esp-open-sdk, чтобы он применял патчи к gcc 4.8.5, а не 4.8.2, который, видимо в lx106. Toolchain собрался, но симптомы при сборке тестового проекта этим тулчейном те же.

У меня еще _sbrk_r была застаблена случайно. Если убрать, то в неразрешенных символах начинает появляться еще и это:

Спойлер: ЭТО

/opt/lx106/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libc.a(lib_a-mallocr.o): In function `malloc_extend_top':
/home/andrey/esp-open-sdk/crosstool-NG/.build/src/newlib-2.0.0/newlib/libc/stdlib/mallocr.c:2165: undefined reference to `_sbrk_r'
/home/andrey/esp-open-sdk/crosstool-NG/.build/src/newlib-2.0.0/newlib/libc/stdlib/mallocr.c:2202: undefined reference to `_sbrk_r'
/opt/lx106/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libc.a(lib_a-freer.o).literal+0x14): undefined reference to `_sbrk_r'
/opt/lx106/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libc.a(lib_a-freer.o): In function `_malloc_trim_r':
/home/andrey/esp-open-sdk/crosstool-NG/.build/src/newlib-2.0.0/newlib/libc/stdlib/mallocr.c:3325: undefined reference to `_sbrk_r'
/home/andrey/esp-open-sdk/crosstool-NG/.build/src/newlib-2.0.0/newlib/libc/stdlib/mallocr.c:3332: undefined reference to `_sbrk_r'

Вопрос, кто бы мог ссылаться на malloc/free в libc? Может это на какие-то мысли наведет что я делаю не так.

 

[Sermus]

@jcmvbkbc
А можно Ваши билдлоги для примера, попробую повторить и разобраться в чем же дело.

 

[Sermus]

Подумал, вдруг esp-open-sdk чего-нибудь оверрайдит в настройках или того паче патчит, поэтому собрал тулчейн из свежесклонированного crosstool-NG. Нет, результат тот же. До тех же функций недотягивается.

 

[jcmvbkbc]

А можно Ваши билдлоги для примера, попробую повторить и разобраться в чем же дело.

Стал проверять и нашёл у себя ошибку: надо было вызвать функцию со stringstream чтобы линковщик её не выкинул за ненадобностью. Теперь и у меня просит файловых операций и _sbrk_r.

До тех же функций недотягивается.

Не "не дотягивается", этих функций просто нет в либах.

 

[Sermus]

Ну хорошо, что результаты сошлись, а то я уже начинал чувствовать себя некомфортно. А реализация функций менеджмента памяти в newlib для lx106 есть? В смысле она через pvPortAlloc/pvPortFree?
Если так, то у Вас есть идеи кто может дергать stuff вроде malloc_extend_top?

 

[Sermus]

Чего-то я не понимаю в том, как дергаются функции.
Если стабов нет, то оно ругается так:
/opt/lx106/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libc.a(lib_a-stdio.o): In function `__sread':
/home/andrey/crosstool-NG/.build/src/newlib-2.0.0/newlib/libc/stdio/stdio.c:48: undefined reference to `_read_r'

Декомпильнул пример со стабами objdump-ом, смотрим реализацию __sread:

401062e4 <__sread>:
401062e4:    f0c112            addi    a1, a1, -16
401062e7:    21c9          s32i.n    a12, a1, 8
401062e9:    20c330            or    a12, a3, a3
401062ec:    079332            l16si    a3, a3, 14
401062ef:    036102            s32i    a0, a1, 12
401062f2:    ebb101            l32r    a0, 401011b8 <system_rtc_mem_read+0xec>
401062f5:    0000c0            callx0    a0
401062f8:    00c296            bltz    a2, 40106308 <__sread+0x24>
401062fb:    142c32            l32i    a3, a12, 80
401062fe:    332a          add.n    a3, a3, a2
40106300:    146c32            s32i    a3, a12, 80
40106303:    000346            j    40106314 <__sread+0x30>
40106306:    420000            excw
40106309:    061c          movi.n    a6, 16
4010630b:    e7f531            l32r    a3, 401002e0 <call_user_start_local+0xa4>
4010630e:    103430            and    a3, a4, a3
40106311:    065c32            s16i    a3, a12, 12
40106314:    3108          l32i.n    a0, a1, 12
40106316:    21c8          l32i.n    a12, a1, 8
40106318:    10c112            addi    a1, a1, 16
4010631b:    f00d          ret.n
4010631d:    000000            ill

Присутствует только один вызов callx0 и objdump думает, что это вызов куда-то внутрь system_rtc_mem_read, что вряд ли правда. Это objdump неправильно считает или я чего-то не понимаю?

 

[Sermus]

Написал скрипт, который визуализирует дерево зависимостей по выводу objdump. Видно, что abort дергается из нескольких мест. А вот другой грязи не видно из-за проблем, описанных в предыдущем посте.
calls.svg

 

[Sermus]

Заставил это добро работать, даже в UART выводит содержимое строкового стрима. Для этого пришлось сделать этакий корявый порт libgloss. Как водится, когда радость поулеглась, и настало подумать все ли в порядке, оказалось, что в порядке не все. А не в порядке вот почему. newlib собран так, что сам определяет функции управления памятью. Не проблема определить malloc/free/realloc у себя, но некоторые части newlib пользуют, например, реентерабельные варианты _malloc_r и поэтому зависят от newlib'овского менеджера памяти, что, насколько я понимаю, ой как плохо.

 

[jcmvbkbc]

Декомпильнул пример со стабами objdump-ом, смотрим реализацию __sread:

401062e4 <__sread>:
...
401062f2:    ebb101            l32r    a0, 401011b8 <system_rtc_mem_read+0xec>
401062f5:    0000c0            callx0    a0

Присутствует только один вызов callx0 и objdump думает, что это вызов куда-то внутрь system_rtc_mem_read, что вряд ли правда. Это objdump неправильно считает или я чего-то не понимаю?

Второе. system_rtc_mem_read+0xec -- это адрес, по которому хранится адрес функции. Если линковать оставляя фиксапы (ключ линковщика -q), то в выводе objdump будут и адреса функций.

 

[Sermus]

Ага, спасибо, ценное знание.
Я создaл pull request в ветку xtensa-1.22.x с -DMALLOC_PROVIDED для newlib. Смысла в функциях управления памятью newlib, вроде, смысла нету, потому что у Espressif свои, а их сосуществование все равно невозможно. Я сделал маленькую либу с реализацией malloc/calloc/free и syscalls. Включу ее в esp-open-sdk. Эти изменения тоже уже готовы, я жду только принятия pull request в crosstool-ng.

Со всеми этими изменениями libc и libstdc++, вроде, полноценно работают. Чтобы доказать это самому себе я спортировал SGI STL test suite из 220+ тестов на ESP8266, выполнил его и сравнил результаты с хостовым x86 GCC. Тест дошел до конца, результаты идентичные.