свежак KGP win32/arm/avr/mips/m68k, GNU tools chain Опции

[klen]

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

[Шаманъ]

также до кучи то чем это собиралось
...........
таргет/хост 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]

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

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

[Шаманъ]

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

Сообщение отредактировал Шаманъ - Mar 3 2017, 14:26

[klen]

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

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

[Шаманъ]

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

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

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

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

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

[Шаманъ]

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

[Шаманъ]

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

[Terminator]

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

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

[Шаманъ]

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

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

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

[klen]

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

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

[Шаманъ]

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

Да в "стандартной версии" тоже не без проблем - проект разросся и -flto почему-то перестало давать прежний эфект. Теперь с -flto работает медленнее в полтора раза, чем без него .

Копания в истории изменений проекта ничего не дало - нашел "переход", где -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]

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

[Шаманъ]

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

Сообщение отредактировал Шаманъ - May 14 2017, 18:33

[klen]

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


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