[klen 1]

свежак 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

[Шаманъ 0]

также до кучи то чем это собиралось

...........

таргет/хост 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]

А реально этим пересобрать arm-none-gdb? Хочу собрать с этим https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054 патчем.

более чем реально

[Шаманъ 0]

Ну вот пересобрал 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]

Да, боьшой проект под Cortex-M7 последней сборкой собрался без проблем, отладчик в связке с VSCode из этой сборки работает лучше, чем из arm-none-eabi (тот несколько раз просто вылетал, оставляя за собой stackdump :))

собрался это понятно.. а скорость? по сравнению с *-none-*

 

[Шаманъ 0]

собрался это понятно..

Предыдущая версия не собирала почему-то...

 

а скорость? по сравнению с *-none-*

С пристрастием не пытал, но большого прогресса или регресса не наблюдалось точно (загрузка процессора не поменялась более чем на 1..2%). Будет время может сравню.

 

Есть такой момент сам компилятор работает значительно (раза в четыре) медленнее, чем arm-none-eabi

[Шаманъ 0]

Поэкспериментировал с -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 указанный при компиляции/компоновке), что очень сильно напрягает.

[Шаманъ 0]

Разобрался, собрал. С lto cборка ZINGIBER медленнее почти в 3 раза...

[Terminator 0]

Разобрался, собрал. С lto cборка ZINGIBER медленнее почти в 3 раза...

Как разобрался?

[Шаманъ 0]

Как разобрался?

Включил опцию -save-temps у компоновщика, ассемблерный файл стал доступен для анализа, посмотрел где возникает ошибка. Ошибка возникала по всему из-за неправильной работы ассемблера, который неправильно разворачивал псевдоинструкции вида:

ldr R4,=XXXXX

 

Переделал эти псевдоинструкции на обычные ldr + ячейка с нужным содержимым регистра, все заработало.

[klen 1]

Разобрался, собрал. С 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

 

какая версия "стандартного" компиллера?

соберу и погоняю, посмотрю разницу , поковыряюсь.

 

[Шаманъ 0]

печалька....

Да в "стандартной версии" тоже не без проблем - проект разросся и -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]

свежак.

для 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 ветки для сравнения.

 

[Шаманъ 0]

для 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]

Не собирается:

 

 

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 вынужден что то чужое использовать.