klen 1 23 июня, 2011 Опубликовано 23 июня, 2011 · Жалоба НАсчёт архива сборок... Где смотреть? На страничке http://klen.org/Projects/Embeded-gnu-tools...cc_archive.html все ссылки в этой ветке форума. только новости от 2006 года... вот и я тоже считаю что пора прорядок в сарайчике навести. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 23 июня, 2011 Опубликовано 23 июня, 2011 · Жалоба Для AVR, хост windows-x86 есть? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 23 июня, 2011 Опубликовано 23 июня, 2011 · Жалоба Для AVR, хост windows-x86 есть? windows-x86 скольтки разрядной ? я на AVR подзабил, у меня нет и не будет на нем проектов. крайний раз когда пробовал собирать были глюки в генераторе отладочной информации в формате DWARF - компиллер падал при попытке ее формирования для компиляймого файла. тоесть можно было собирать проектв но без отладочной информации, я не стал выкладывать такое. для порта avr было вообще все нафиг разломано и брошен. я попробую посмотреть есть ли новости в транке по этому поводу. если ктото пытался починить то попробую собрать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 23 июня, 2011 Опубликовано 23 июня, 2011 · Жалоба windows-x86 скольтки разрядной ? я на AVR подзабил, у меня нет и не будет на нем проектов. крайний раз когда пробовал собирать были глюки в генераторе отладочной информации в формате DWARF - компиллер падал при попытке ее формирования для компиляймого файла. тоесть можно было собирать проектв но без отладочной информации, я не стал выкладывать такое. для порта avr было вообще все нафиг разломано и брошен. я попробую посмотреть есть ли новости в транке по этому поводу. если ктото пытался починить то попробую собрать. Windows, 32 бита. Пигмей в квадрате. Отладка не интересует, dwarf вормировать не буду. Если от winavr издания ноября 2010 года не будет отличаться, не заморачивайтесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 23 июня, 2011 Опубликовано 23 июня, 2011 · Жалоба Если от winavr издания ноября 2010 года не будет отличаться, не заморачивайтесь. а как узнать без сборки? я не шаман :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ash_snz 0 25 июня, 2011 Опубликовано 25 июня, 2011 · Жалоба освеженная сборка для комдивчика на x86_32 масдай ...Инет заработал, спасибо за код. Будем копать! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
en1gma 0 26 июня, 2011 Опубликовано 26 июня, 2011 · Жалоба по-тихоньку, присоединяюсь к тестированию сборок под 5980ВЕ, не даром, АФАИК, это чудо было сделано по заказу нашего предприятия, да и я с ним мучаюсь уже 2,5 года.. кстати, очень интересны результаты переговоров с НИИСИ, так как свой компилятор они в комплект процам не предоставляют, а предпочитают его всё же продавать. кроме того, будет интересен дальнейших ход событий с дебагером.. P.S. код, собираемый gcc 3.хх с mips-таджетом (-march=r3000 -mhard-float) в своё время на железе не запускался.. требовались какие-то "комдив32"-совместимые патчи, поэтому использовали и используем до сих пор их компилятор Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 27 июня, 2011 Опубликовано 27 июня, 2011 · Жалоба по-тихоньку, присоединяюсь к тестированию сборок под 5980ВЕ, не даром, АФАИК, это чудо было сделано по заказу нашего предприятия, да и я с ним мучаюсь уже 2,5 года.. кстати, очень интересны результаты переговоров с НИИСИ, так как свой компилятор они в комплект процам не предоставляют, а предпочитают его всё же продавать. кроме того, будет интересен дальнейших ход событий с дебагером.. P.S. код, собираемый gcc 3.хх с mips-таджетом (-march=r3000 -mhard-float) в своё время на железе не запускался.. требовались какие-то "комдив32"-совместимые патчи, поэтому использовали и используем до сих пор их компилятор это потрясающе.... сейчас я общаюсь с тремя анонимно разработчиками(или группами - мне не известно) которые используют комдив32. что вас объеденяет? комдив? не только! вы все какие то мутные. если так будет продолжатся то я плюну и брошу это неблагодарное занятие. Выложил две сборки - бери тестируй, что то расковыряли - сообщили, я подкрутил - опять проверили и т.д. НИЧЕГО - одни какие то рассуждения о непонятно о чем. Ни один из Вас так и не сообщил мне - пробовали ли компилять моей сборкой или нет и что получилось/не получилось. напоминаю закон из теории автоматики - система без обратной вязи как правило уходит в устойчивое насыщенное состояние, а если хватает мощи источника энергии - разрушается. я близок к насыщению по данному вопросу. по поводу "требовались какие-то "комдив32"-совместимые патчи,..." ребята... Вы сначала хотя бы определите ревизию кристалла которые Вы мучаете, а потом про патчи говорите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
en1gma 0 27 июня, 2011 Опубликовано 27 июня, 2011 (изменено) · Жалоба объясню достаточно просто, цена на это чудо-юдо на текущий момент составляет 90 тысяч рублей за штучку - поэтому оно совсем не популярно.. только в определенном секторе.. и только по принуждению сверху.. второе, "настоящие программисты" (ну те, кто так значится по штатному расписанию и кто отвечает головой за код) это дядечки далеко за 40 и они особо баловаться не будут (наши-то записать бинарь во флешку не всегда могут да, например, пишут в кейл 2.х, так как кейл 3.х "не так выглядит") третье, твоя сборка (или как это назвать, чтобы было верно по-научному) преспокойно собирает ассемблеровский код (было бы удивительно если не собирала) и достаточно простой С-код, осуществляющие чуть больше чем запись/чтение в память и дрыганье ножками четвёртое, серии кристаллов ведут себя по-разному. "а в этой партии вот то, то и то не реализовано или реализовано криво"(с). кроме того списка "время выпуска / партия"-"ревизия"-"список ошибок" как-то не попадалось пятое, будем очень благодарны если будет собираться под вин32 хост с таджетом "сферический" мипс, в котором есть библиотеки как для софтового (чтобы дружило с тем же пик32) так и для железного флоата, так как, в моём случае, на мипсе2 на ~20МГц и полумегабайтами озу и пзу не до фортрана и тем более не до с++ зы простите нас не_разумных Изменено 27 июня, 2011 пользователем en1gma Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 28 июня, 2011 Опубликовано 28 июня, 2011 · Жалоба объясню достаточно просто, цена на это чудо-юдо на текущий момент составляет 90 тысяч рублей за штучку - поэтому оно совсем не популярно.. только в определенном секторе.. и только по принуждению сверху.. второе, "настоящие программисты" (ну те, кто так значится по штатному расписанию и кто отвечает головой за код) это дядечки далеко за 40 и они особо баловаться не будут (наши-то записать бинарь во флешку не всегда могут да, например, пишут в кейл 2.х, так как кейл 3.х "не так выглядит") третье, твоя сборка (или как это назвать, чтобы было верно по-научному) преспокойно собирает ассемблеровский код (было бы удивительно если не собирала) и достаточно простой С-код, осуществляющие чуть больше чем запись/чтение в память и дрыганье ножками четвёртое, серии кристаллов ведут себя по-разному. "а в этой партии вот то, то и то не реализовано или реализовано криво"(с). кроме того списка "время выпуска / партия"-"ревизия"-"список ошибок" как-то не попадалось Вы таки думаете что я первый раз замужем? а вот нет! развелся! завязал я со службой государевой. и то что Вы написали сверху для меня не хужлитература а тоска и безнадега в которой 15 лет провел. Всецело понимаю и сочувствую. пятое, будем очень благодарны если будет собираться под вин32 хост с таджетом "сферический" мипс, в котором есть библиотеки как для софтового (чтобы дружило с тем же пик32) так и для железного флоата, так как, в моём случае, на мипсе2 на ~20МГц и полумегабайтами озу и пзу не до фортрана и тем более не до с++ пол мегабайта???? да это вселенная. я больше 64к пока не встречал. однако с успехом использую и фортран и С++. уверяю, то что "С++ это не то что походит к микроконтроллерам" - глубочайшее заблуждение порожденное непонятно чем. я специально пытался это понять но размного ответа не нашел. Вопрос в том что все нужно умело применять. сферический мипс это здорово! в данной ветке выкладывается одна из сборок специально для юзателей pic32 - такчто уже все "было". в ней софтовая плавучка а для комдива с железной. зы простите нас не_разумных no comments есть прогресс. один из разработчиков написал письмо что у них все заработало - что заработало и как неизвестно, но по тону письма, выражающему позитив, видимо заработал код на комдиве собранный kgp. вот... жду подробностей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 3 июля, 2011 Опубликовано 3 июля, 2011 · Жалоба все свежаки которые я собираю - собираются из транка, если всплывают косяки я их по возможности правлю чтоб собралось, потом тестирую в силу возможности и тоже правлю если опятже косяки в кодогенерации. То есть по сути - сборки экспериментальные и могут работать с ошибками. Но сегодня сборка экспеерментальная в квадрате. я потратил время на то чтоб разобратся с LTO + Gold. LTO - оптимизация времени линкования. те кто еще не интересовался что это такое то можно почитать тут (коротко на русском) http://kemiisto.blogspot.com/2010/08/gcc-4...timization.html и тут http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gc...ptimize-Options GOLD (gnu ld.gold) - это новый эксперементальный линкер который возможно заменит классический LD (gnu ld.bfd). штатно входит в binutils. Google и многие проекты - LLVM, GNU итд, его используют тестируют и девелопят как основной. основным локомотивом его разработкии внедрения является google. в маках кажется тоже он штатно используется. не для кого не секрет что в больших проектах (не таких как у нас - эмбедеров) основное время сборки занимает линковка. поскольку Gold был задуман как линкер больших проектов, его рамках сразу делали LTO. до сегодняшнего дня у меня LTO не работало - я тестировал на сложном проекте, использовал обчный LD, проект состоял и з можества собранных либ и тд. пришло время..... итак. сегодняшняя сборка по умолчанию использует в качестве линкера Gold. все библиотеки GCC и newlib собраны c опцией -flto. проект собирался тоже с -flto. речь будет идти про arm таргет. код генерится рабочий. но есть нюансы... 1. при линковке нада передавать также и флаги оптимизации ! если не передать то линковка падает. ( ув. тов. АНТОХА это обнаружил раньше меня ). я думаю это ошибка в компиллере - эти флаги и так можно хранить в секциях объектника да еще они могут быть разными у разных объектиков 2. LTO - это реально ЖЕСТЬ!!!!!. после первой сборки я обнаружил что проект уменьшился в два раза.... начал ковырять. оказалось оптимайзер нафег выкинул таблицу векторов прерываний! выкинул функции - обработчики прерываний и тд много чего. я сначала ошалел - а потом попробывал представить сябя на его месте. и действительно - таблица векторов это тупо массив байтов. он же не знает что это такое. к этому массиву из кода не происходит никаких обращений - значить это мертвое - отрезаем... обработчики исключений - таже истоия - они "апаратно" вызываются.. и так далее и тому подобное. для того чтоб вернут взад вектора я сделал в crt коде одно фиктивное обращение к таблице на чтение содержимого - и Gold впечатленный этим оставил структуру в котой у менф оформлена таблица векторов в покое - она появилась в бинарнике с нужного адреса. далее некоторым функция пришлось воткнуть атрибут externally_visible чтоб он их не выкидывал. 3. есть шаманство с вызовом main из crt кода, с другими функциями я не заметил такого. както очень хитро это происходит. надо разбираться. 4. если функция вызывается из асемблерной вставки - то ни комиллер ни голд это отследить не может и выкидывает ее как ненужную, далее получаем неразрешенную ссыку на конечном этапе линкования. в этом случае надо помечать такую функцию атрибутом externally_visible примером такой функции может служить void xPortPendSVHandler( void ) из FreeRTOS 5. линкер выдает мессагу которую я пока не понял юмора : /opt/arm-kgp-eabi/lib/gcc/arm-kgp-eabi/4.7.0/../../../../arm-kgp-eabi/bin/ld: warning: creating a segment to contain the file and program headers outside of any MEMORY region 6. РЕЗУЛЬТАТЫ сборка от 19 числа стандартный линкер ld.bfd без LTO memutz .././../out/image.elf 512K 64K section info: sec name size increase[%] .text 18728 0 (0.000000%) .data 260 0 (0.000000%) .bss 33256 0 (0.000000%) utilization: ram : 51.1414% 0 (0.000000%) flash: 3.62167% 0 (0.000000%) c LTO section info: sec name size increase[%] .text 15816 -2912 (-15.548909%) .data 202 -58 (-22.307694%) .bss 33245 -11 (-0.033075%) utilization: ram : 51.0361% -69 (-0.205874%) flash: 3.05519% -2970 (-15.641457%) бинарь не работает - изгажен crt. видимо както можно заставить но у меня не получилось, явно видно что выкинул и то что нужно! как он смог слинковать после этого!?? нада дифы листингов курить... сегодняшняя сборка с Gold без LTO section info: sec name size increase[%] .text 18768 0 (0.000000%) .data 260 0 (0.000000%) .bss 33256 0 (0.000000%) utilization: ram : 51.1414% 0 (0.000000%) flash: 3.6293% 0 (0.000000%) сегодняшняя сборка с Gold c LTO section info: sec name size increase[%] .text 15992 -2776 (-14.791131%) .data 528 268 (103.076935%) .bss 35201 1945 (5.848575%) utilization: ram : 54.5181% 2213 (6.602812%) flash: 3.15094% -2508 (-13.180578%) РАБОТАЕТ!!!!! НО..... что он делает с кодом ! я в листингах ваще концы найти не могу. отладчик уходит в астрал и в состоянии только остановить и пустить код далее - ничего более, даже адреса глобальных переменных определить не может. глядя асм видно что функций уже видимо нет! все нахрен так перемешано что там где ранее были переходы из дной функции в другу - их там просто нет - линейный код! полный ахтунг. но подчеркиваю - оно както работает. что честно говоря изумляет. у меня сложный проект на С++ с испоьзование вычисленй на плавучке и FreeRTOS - гденибудь да вылез бы косяк, однакож честно все считается и работает. 6, видно что зачемто LTO увеличивает расход ОЗУ, что это косяг или так вынуждено - пока не исследовал. нада файлы мапы памяти смотреть и разбиратся. пожже. 7. есть недостаток но для нас эмбеддеров не существенный - преред линковкой все объектиники загоняются в память и ликер по ним ходит и отимизирует. соответственно слинковать проект объем объектников которо больше чем ОЗУ хост машины - нельзя, правдв идет работа у разработчиков чтоб это кусками можно былобы делать. 8. довольно долго GDB учили понимать отоптимайщеный код - научили. затем очень доло его учили понимать код сгенеренный компиллером C++ (шаблончики, виртуальные методы и конструкторы в сошках и прочая...) типа щас более менее но не всегда цепляестя за код. С LTO видимо будет полная попа - на выходе настолько не то "что вы имели ввиду" что похоже отладчикам ничего не светит даже в отдаленной перспективе. хотя кто знает.... про дебаг неоптимизированного кода я не говорю - считаю актом практически не несущим новой информации в эмбедед. 9. в итоге видим что LTO вещ чумовая и сравнительно новая, неустоявшаяся. но на мой взгляд это реальный идейный прорыв в методах оптимизации. на данный момент все в стадии отработки и вопросов пока больше чем ответов. все это можно поробывать в действии - сборка для хоста linux 64bit http://klen.org/Files/DevTools/linux-x86_6...ld-lto.tar.lzma Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 4 июля, 2011 Опубликовано 4 июля, 2011 · Жалоба я сначала ошалел - а потом попробывал представить сябя на его месте. и действительно - таблица векторов это тупо массив байтов. он же не знает что это такое. к этому массиву из кода не происходит никаких обращений - значить это мертвое - отрезаем...Если этот линкер использует скрипты того же формата, что и старый - то достаточно в скрипте обрамить нужные секции в KEEP() и ничего не будет выкидываться без всяких шаманств с фиктивными обращениями. Такое и раньше происходило по --gc-sections. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 4 июля, 2011 Опубликовано 4 июля, 2011 · Жалоба Если этот линкер использует скрипты того же формата, что и старый - то достаточно в скрипте обрамить нужные секции в KEEP() и ничего не будет выкидываться без всяких шаманств с фиктивными обращениями. Такое и раньше происходило по --gc-sections. в тероии. а на практике ........ .text : { _image_start_ = .; _vec_start_ = .; KEEP(*(.flash_vec_table*)) _vec_end_ = ALIGN( . , 8); ....... выкинул структуру с векторами которая укладыватся в секцию flash_vec_table без lto не выкидывает. еще предстоит понять как скрипт линкера влияет на lto, наверняка что вылезет новое. линкер то другой! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vlab2000 0 17 июля, 2011 Опубликовано 17 июля, 2011 · Жалоба Спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 7 августа, 2011 Опубликовано 7 августа, 2011 · Жалоба свежак для ARM хост linux x86_64 http://klen.org/Files/DevTools/linux-x86_6...110807.tar.lzma размер 81Mb openocd стал (насколько мне удалось натестить) хорошо работать с stm32f2xx Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться