klen 1 2 марта, 2017 Опубликовано 2 марта, 2017 · Жалоба свежак arm хост lin64 http://klen.org/Files/DevTools/x86_64-kgp-...301_ZINGIBER.7z хост win64 http://klen.org/Files/DevTools/x86_64-kgp-...302_ZINGIBER.7z также до кучи то чем это собиралось таргет/хост lin64 http://www.klen.org/Files/DevTools/x86_64-...301_ZINGIBER.7z таргет win64 хост lin64 http://www.klen.org/Files/DevTools/x86_64-...301_ZINGIBER.7z таргет/хост win64 http://www.klen.org/Files/DevTools/x86_64-...302_ZINGIBER.7z Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 2 марта, 2017 Опубликовано 2 марта, 2017 · Жалоба также до кучи то чем это собиралось ........... таргет/хост win64 http://www.klen.org/Files/DevTools/x86_64-...302_ZINGIBER.7z А реально этим пересобрать arm-none-gdb? Хочу собрать с этим https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054 патчем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 2 марта, 2017 Опубликовано 2 марта, 2017 · Жалоба А реально этим пересобрать arm-none-gdb? Хочу собрать с этим https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054 патчем. более чем реально Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 3 марта, 2017 Опубликовано 3 марта, 2017 (изменено) · Жалоба Ну вот пересобрал gdb из исходников arm-none-eabi, там патч этот по идее уже есть, но нормального bt (на Cortex-Mx) так и нет :( То ли при переходе с 7.11 на 7.12 что-то поломали, то ли оно и не работало нормально :( Обидно - полдня потратил на собирательства gdb под виндой, и такой облом :( Проверил три варианта gdb: 1. Бинарник от АРМа (бывший ланчпад, как я понимаю) 2. Собранный из исходников оттуда же 3. Из сборки на несколько постов выше (от klen) Все три при задействовании наскольких стеков и двух указателей PSP/MSP при попытке развернуть стек из прерывания выдают полную хрень в bt :( . Причем что интересно все три выдают разные результаты. Эх нет гармонии, придется по старинке скриптами gdb, да руками... Да, боьшой проект под Cortex-M7 последней сборкой собрался без проблем, отладчик в связке с VSCode из этой сборки работает лучше, чем из arm-none-eabi (тот несколько раз просто вылетал, оставляя за собой stackdump :)) Изменено 3 марта, 2017 пользователем Шаманъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 3 марта, 2017 Опубликовано 3 марта, 2017 · Жалоба Да, боьшой проект под Cortex-M7 последней сборкой собрался без проблем, отладчик в связке с VSCode из этой сборки работает лучше, чем из arm-none-eabi (тот несколько раз просто вылетал, оставляя за собой stackdump :)) собрался это понятно.. а скорость? по сравнению с *-none-* Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 3 марта, 2017 Опубликовано 3 марта, 2017 · Жалоба собрался это понятно.. Предыдущая версия не собирала почему-то... а скорость? по сравнению с *-none-* С пристрастием не пытал, но большого прогресса или регресса не наблюдалось точно (загрузка процессора не поменялась более чем на 1..2%). Будет время может сравню. Есть такой момент сам компилятор работает значительно (раза в четыре) медленнее, чем arm-none-eabi Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 27 апреля, 2017 Опубликовано 27 апреля, 2017 · Жалоба Поэкспериментировал с -flto. Интересная штука -O3 c -flto дало до 40% прирост производительности по сравнению с просто -О3 (это на "стандартном" gcc). Решил проверить на gcc от klen, но увы - последняя сборка не смогла собрать проект с -flto: Linking... C:\Users\08A4~1\AppData\Local\Temp\ccApIkMP.s: Assembler messages: C:\Users\08A4~1\AppData\Local\Temp\ccApIkMP.s:2704: Error: offset out of range C:\Users\08A4~1\AppData\Local\Temp\ccApIkMP.s:3017: Error: offset out of range C:\Users\08A4~1\AppData\Local\Temp\ccApIkMP.s:3118: Error: offset out of range C:\Users\08A4~1\AppData\Local\Temp\ccApIkMP.s:3175: Error: offset out of range lto-wrapper.exe: fatal error: C:\arm\bin\arm-kgp-eabi-gcc.exe returned 1 exit status compilation terminated. c:/arm/bin/../lib/gcc/arm-kgp-eabi/7.0.1/../../../../arm-kgp-eabi/bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status Есть какая-то возможность указать gcc не удалять этот временный файл, чтобы можно было понять где проблема? Положительный момент по сборкам от klen - в его сборках отладочная информация по макросам формируется правильно и gdb ее правильно "переваривает", в сборке от ARM gdb не может вытянуть информацию по макросам (не смотря на -ggdb3 указанный при компиляции/компоновке), что очень сильно напрягает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 27 апреля, 2017 Опубликовано 27 апреля, 2017 · Жалоба Разобрался, собрал. С lto cборка ZINGIBER медленнее почти в 3 раза... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Terminator 0 28 апреля, 2017 Опубликовано 28 апреля, 2017 · Жалоба Разобрался, собрал. С lto cборка ZINGIBER медленнее почти в 3 раза... Как разобрался? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 28 апреля, 2017 Опубликовано 28 апреля, 2017 · Жалоба Как разобрался? Включил опцию -save-temps у компоновщика, ассемблерный файл стал доступен для анализа, посмотрел где возникает ошибка. Ошибка возникала по всему из-за неправильной работы ассемблера, который неправильно разворачивал псевдоинструкции вида: ldr R4,=XXXXX Переделал эти псевдоинструкции на обычные ldr + ячейка с нужным содержимым регистра, все заработало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 11 мая, 2017 Опубликовано 11 мая, 2017 · Жалоба Разобрался, собрал. С lto cборка ZINGIBER медленнее почти в 3 раза... печалька.... тем не менее предлагается попробывать 8 ветку ;) www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20170511_GREAT.7z какая версия "стандартного" компиллера? соберу и погоняю, посмотрю разницу , поковыряюсь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба печалька.... Да в "стандартной версии" тоже не без проблем - проект разросся и -flto почему-то перестало давать прежний эфект. Теперь с -flto работает медленнее в полтора раза, чем без него :laughing: . Копания в истории изменений проекта ничего не дало - нашел "переход", где -flto перестал себя адекватно вести, но что конкретно ему не нравится понять сложно - изменения были в функциях, которые во время "замера производительности" вообще не вызываются (а времени заниматься причудами оптимизатора GCC нет, да и смысла особого нет). тем не менее предлагается попробывать 8 ветку ;) www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20170511_GREAT.7z Если под windows сделаете, то попробую и отпишусь, тем более вопрос производительности с недавних пор для меня стал достаточно актуальным. какая версия "стандартного" компиллера? соберу и погоняю, посмотрю разницу , поковыряюсь. 6.3.1 https://developer.arm.com/open-source/gnu-t...nu-rm/downloads Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 14 мая, 2017 Опубликовано 14 мая, 2017 · Жалоба свежак. для linux64 www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20170513_OCIMUM.7z 2_Шаманъ пробуйте сборку под масдай64, проверил под wine - кажись дышит.. для Win64 www.klen.org/Files/DevTools/x86_64-kgp-mingw32/arm-kgp-eabi_@_x86_64-kgp-mingw32_20170514_OCIMUM.7z чуть пожже выложу крайние релизы 6 и 7 ветки для сравнения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 14 мая, 2017 Опубликовано 14 мая, 2017 (изменено) · Жалоба для Win64 www.klen.org/Files/DevTools/x86_64-kgp-mingw32/arm-kgp-eabi_@_x86_64-kgp-mingw32_20170514_OCIMUM.7z Не собирается: Linking... C:\Users\08A4~1\AppData\Local\Temp\cc6wJPuA.ltrans1.ltrans.o: In function `VCPStart': Soft\Ctrl2\Ctrl/VCP.c:140: undefined reference to `memset' C:\Users\08A4~1\AppData\Local\Temp\cc6wJPuA.ltrans1.ltrans.o: In function `clust2sect': Soft\Ctrl2\Ctrl/ff.c:988: undefined reference to `memset' C:\Users\08A4~1\AppData\Local\Temp\cc6wJPuA.ltrans1.ltrans.o: In function `entryNVRAMTask': Soft\Ctrl2\Ctrl/Settings.c:135: undefined reference to `memcpy' C:\Users\08A4~1\AppData\Local\Temp\cc6wJPuA.ltrans1.ltrans.o: In function `entryDisplayTask': Soft\Ctrl2\Ctrl/Display.c:570: undefined reference to `memset' C:\Users\08A4~1\AppData\Local\Temp\cc6wJPuA.ltrans0.ltrans.o: In function `FrontSendCmd': Soft\Ctrl2\Ctrl/Keyb.c:304: undefined reference to `memmove' C:\Users\08A4~1\AppData\Local\Temp\cc6wJPuA.ltrans0.ltrans.o: In function `Reset_Handler': ................ 8.0.0 намного быстрее компилирует, раза в четыре наверное. Кстати обнаружил причину странного поведения -flto. Если задать вместе с -flto генерацию отладочной информации (-g), то что-то ломается и lto не работает (об этом есть намек в доках, собственно когда его увидел и решил проверить). Пересобрал ради интереса проект компилятором 7.0.1 (от klen) еще раз без -g, теперь разница со "штатным" GCC около 10%, по прежнему в пользу "штатного" 6.3.1. Изменено 14 мая, 2017 пользователем Шаманъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 14 мая, 2017 Опубликовано 14 мая, 2017 · Жалоба Не собирается: 8.0.0 намного быстрее компилирует, раза в четыре наверное. Кстати обнаружил причину странного поведения -flto. Если задать вместе с -flto генерацию отладочной информации (-g), то что-то ломается и lto не работает (об этом есть намек в доках, собственно когда его увидел и решил проверить). Пересобрал ради интереса проект компилятором 7.0.1 (от klen) еще раз без -g, теперь разница со "штатным" GCC около 10%, по прежнему в пользу "штатного" 6.3.1. хорошо а в качестве эксперемента можете подсунуть "руками" memset/memcpy/memmove? чтоб результат погдядеть... я к счастью ничем внешним не пользуюсь, даже libc и libm свои "местные" в исхниках, в связи с чем никакие либы кроме libgcc самого компиллера в проект не линкуются и все на лету генерится из исходников, идея - сделать максимально быстрый бинарный код. для универсальности и чтоб другие могли воспользоваться моей сборкой в ней присутствует newlib, от его кода меня воротит но .... кто не хочет сам писать libc и libm вынужден что то чужое использовать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться