А lib к ним?
Все эти libppl_c.so.4 и компания. А то у меня от прошлого разворачивания (еще 20100525 или что-тов этом духе) там аж libppl_c.so.2 и с прочим аналогично.

upd:
Ага, оно в x86_84-kgp-linux, только этот архив у меня что-то при распаковке ругается в духе "попросили распаковать, а такой файл уже есть" (распаковываю в ~/downloads, там такого точно ен было ещё). Потом разберусь, опять убегаю...

я их перекидываю в дистр, в данном случае наверно спешил и забыл.

свежак ARM для хоcта linux x86_64

http://www.klen.org/Files/DevTools/linux-x...abi-20110924.7z

обновился GDB до версии 7.3.1
openocd собран с подержкой:
ft2232 устройств
jlink
rlink
usb_blaster
amtjtagaccel
zy1000-master
presto
usbprog
vsllink
ulink
arm-jtag-ew
buspirate

в /doc лежит сгенеоенная pdf дока по openocd

binutilsтеперь будет собиратся c обоими линкерами - ld и gold
рекомендую разработчикам больших проектов в которых линковка занимает большое время попробывать gold. я лично першел на него полностью - пока нигде проблем не возникло.

после длительного тестироваия оптимизации LTO принял решение использовать это шаманство с бубном в рабочих проектах при необходимости.
таким образом все либы в сборках будут компилятся с поддержкой LTO, для тех кто не скажет линкеру оптимизировать это останется прозрачным.
вот типовой выхлоп этой оптимизации на моем рабоче-тестовом проетке
11 задач FreeRTOS + одна для програмных таймеров + одна idle
большинство объектов динамически реазмещаются в куче
работет переферия I2C для чтения акселерометра
осуществяется вывод перегрузок на ЖКИ
выполняетя плавучка - преобразование Гильбера, пересчет системы координат акселерометра,
организован обмен по USB
реализовано на С++
FreeRTOS обернта в классы
имеются виртуальныей функции
тоетсь проекти не такой уж и примитивный

результат сборки без LTO
memutz .././../out/image.elf 512K 64K
section info:
sec name size increase[%]
.text 22416 0 (0.000000%)
.data 512 0 (0.000000%)
.bss 33270 0 (0.000000%)
utilization:
ram : 51.5472% 0 (0.000000%)
flash: 4.37317% 0 (0.000000%)

результат сборки c LTO
memutz .././../out/image.elf 512K 64K
section info:
sec name size increase[%]
.text 19656 -2760 (-12.312633%)
.data 539 27 (5.273438%)
.bss 35234 1964 (5.903220%)
utilization:
ram : 54.5853% 1991 (5.893672%)
flash: 3.85189% -2733 (-11.919922%)


итого видно что в конкретном случае по флешу ужатие 11%
по озу 5% в гору
что на мой взгляд выдающийся результат для отдельного метода оптимизации.
разумеется после зашивки девайс работает аналогичо. скоростные характеристики кода не исследовал.
напомню что в линкер нада пропихивать тотже ключ оптимизации как и при компиляции. в данном случае -Os -flto

на подходе cortex M4F.. вот покуражимсо! ждем и потираем руки..

Как обычно, приму с юлагодарностью ARM для хоста WIM32

ежики самцы кололись и рыдали от боли но упорно лезли на кактусы..

по ходу обновил сборку mingw32
http://klen.org//Files/DevTools/mingw32/i6...w32_20110925.7z

сборка ARM для win32
http://klen.org//Files/DevTools/mingw32/ar...w32_20110925.7z

не тестировал

Я в своей пигмейской жизни разрабатываю встроенные системы сидя под виндами, использую для облегчения работы автотрассировку печатных плат и не хочу лезть на кактус под называнием пингвин_на_рабочем_столе.

Ёжики не лезут на пингвинов.

Протестирую.

ps: протестировал: LTO с ARM7 отвалилось (Segmentation fault в lto1.exe).
Жду следующей версии. В позапрошлом варианте работало - пока сижу на нём. Не колет.

Сообщение отредактировал Genadi Zawidowski - Sep 25 2011, 12:58

прискорбно, какнибудь помотрю и попробую разобратся.
LTO в Ваших задачах безусловно необходим? если да то расскажите поподробней почему.

без LTO новая сборка дголжна быть лучше, как минимум GDB обновили - стал более адекватно сложные вещи выполнять.

Нет, LTO критически необходимым не является - пока ещё до предела в ПЗУ не дошёл. Просто отваливание этого куска выглядит как индикатор того, что что-то не так в оптимизаторе.

Хотя... Была идея запихнуть проект в 32-килобайтный процессор (с LTO - 25 кБ, без - 33 кБ)... пока можно пользоваться старой версией.
GDB не пользуюсь...

Господа, имеет место такая вещь:
Сборка с ключом оптимизации -О2 создает вечный цикл в 2 команды в виде джампа на самого себя. Без -О2 такого не наблюдается и все работает. Было сделано предположение, что один из внутренних ключей -О2 дает такой эффект.
Из интернетовских источников был развернут -О2 на составляющие флаги, НО! -> размер бинарника не сократился в той же мере, как при -О2, и к тому же продолжает нагло работать.
Вопрос в том - какие ключи отвечают за оптимизацию бинарника по размеру? кажется собака рылась там.

Сообщение отредактировал Ash_snz - Sep 28 2011, 05:33

Такой жалобы на отсутствующий у жалующегося в коде ключевых слов volatile в нужных местах я еще не видал

Точно! И почему до меня сразу не дошло?! Место в луже мое -O2 заработал!

а ёжиков, которые все еще лезут на AVR с Win32, не пожалеете?

увежаемый klen почему компилер может не находить библиотеку?
Распаковал архив arm-kgp-eabi-20110924.7z в папку /opt/arm-kgp-eabi-20110924, сделал симлинк в /opt/arm-kgp-eabi прописал путь к bin
При попытке откомпилировать gcc валится с таким сообщением об ошибке:
/opt/arm-kgp-eabi-20110924/bin/../libexec/gcc/arm-kgp-eabi/4.7.0/cc1: error while loading shared libraries: libcloog.so.0: cannot open shared object file: No such file or directory

мой косяг видимо. до дома доберусь проверю, корее всего п окакойто причине либа libcloog.so.0 не сложилась в архив или битая. поправим.

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

Сообщение отредактировал _3m - Oct 15 2011, 04:10