Перейти к содержанию
    

НАсчёт архива сборок... Где смотреть? На страничке http://klen.org/Projects/Embeded-gnu-tools...cc_archive.html

все ссылки в этой ветке форума.

 

только новости от 2006 года...

вот и я тоже считаю что пора прорядок в сарайчике навести.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для AVR, хост windows-x86 есть?

windows-x86 скольтки разрядной ?

 

я на AVR подзабил, у меня нет и не будет на нем проектов. крайний раз когда пробовал собирать были глюки в генераторе отладочной информации в формате DWARF - компиллер падал при попытке ее формирования для компиляймого файла. тоесть можно было собирать проектв но без отладочной информации, я не стал выкладывать такое.

для порта avr было вообще все нафиг разломано и брошен.

 

я попробую посмотреть есть ли новости в транке по этому поводу. если ктото пытался починить то попробую собрать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

windows-x86 скольтки разрядной ?

 

я на AVR подзабил, у меня нет и не будет на нем проектов. крайний раз когда пробовал собирать были глюки в генераторе отладочной информации в формате DWARF - компиллер падал при попытке ее формирования для компиляймого файла. тоесть можно было собирать проектв но без отладочной информации, я не стал выкладывать такое.

для порта avr было вообще все нафиг разломано и брошен.

 

я попробую посмотреть есть ли новости в транке по этому поводу. если ктото пытался починить то попробую собрать.

 

Windows, 32 бита. Пигмей в квадрате.

 

Отладка не интересует, dwarf вормировать не буду.

Если от winavr издания ноября 2010 года не будет отличаться, не заморачивайтесь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если от winavr издания ноября 2010 года не будет отличаться, не заморачивайтесь.

а как узнать без сборки? я не шаман :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

освеженная сборка для комдивчика на x86_32 масдай ...
Инет заработал, спасибо за код. Будем копать!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

по-тихоньку, присоединяюсь к тестированию сборок под 5980ВЕ, не даром, АФАИК, это чудо было сделано по заказу нашего предприятия, да и я с ним мучаюсь уже 2,5 года..

кстати, очень интересны результаты переговоров с НИИСИ, так как свой компилятор они в комплект процам не предоставляют, а предпочитают его всё же продавать. кроме того, будет интересен дальнейших ход событий с дебагером..

 

P.S. код, собираемый gcc 3.хх с mips-таджетом (-march=r3000 -mhard-float) в своё время на железе не запускался.. требовались какие-то "комдив32"-совместимые патчи, поэтому использовали и используем до сих пор их компилятор

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

по-тихоньку, присоединяюсь к тестированию сборок под 5980ВЕ, не даром, АФАИК, это чудо было сделано по заказу нашего предприятия, да и я с ним мучаюсь уже 2,5 года..

кстати, очень интересны результаты переговоров с НИИСИ, так как свой компилятор они в комплект процам не предоставляют, а предпочитают его всё же продавать. кроме того, будет интересен дальнейших ход событий с дебагером..

 

P.S. код, собираемый gcc 3.хх с mips-таджетом (-march=r3000 -mhard-float) в своё время на железе не запускался.. требовались какие-то "комдив32"-совместимые патчи, поэтому использовали и используем до сих пор их компилятор

 

это потрясающе....

сейчас я общаюсь с тремя анонимно разработчиками(или группами - мне не известно) которые используют комдив32. что вас объеденяет? комдив? не только! вы все какие то мутные. если так будет продолжатся то я плюну и брошу это неблагодарное занятие. Выложил две сборки - бери тестируй, что то расковыряли - сообщили, я подкрутил - опять проверили и т.д. НИЧЕГО - одни какие то рассуждения о непонятно о чем. Ни один из Вас так и не сообщил мне - пробовали ли компилять моей сборкой или нет и что получилось/не получилось.

 

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

 

по поводу "требовались какие-то "комдив32"-совместимые патчи,..."

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

объясню достаточно просто, цена на это чудо-юдо на текущий момент составляет 90 тысяч рублей за штучку - поэтому оно совсем не популярно.. только в определенном секторе.. и только по принуждению сверху..

второе, "настоящие программисты" (ну те, кто так значится по штатному расписанию и кто отвечает головой за код) это дядечки далеко за 40 и они особо баловаться не будут (наши-то записать бинарь во флешку не всегда могут да, например, пишут в кейл 2.х, так как кейл 3.х "не так выглядит")

третье, твоя сборка (или как это назвать, чтобы было верно по-научному) преспокойно собирает ассемблеровский код (было бы удивительно если не собирала) и достаточно простой С-код, осуществляющие чуть больше чем запись/чтение в память и дрыганье ножками

четвёртое, серии кристаллов ведут себя по-разному. "а в этой партии вот то, то и то не реализовано или реализовано криво"(с). кроме того списка "время выпуска / партия"-"ревизия"-"список ошибок" как-то не попадалось

пятое, будем очень благодарны если будет собираться под вин32 хост с таджетом "сферический" мипс, в котором есть библиотеки как для софтового (чтобы дружило с тем же пик32) так и для железного флоата, так как, в моём случае, на мипсе2 на ~20МГц и полумегабайтами озу и пзу не до фортрана и тем более не до с++

 

зы простите нас не_разумных

Изменено пользователем en1gma

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

объясню достаточно просто, цена на это чудо-юдо на текущий момент составляет 90 тысяч рублей за штучку - поэтому оно совсем не популярно.. только в определенном секторе.. и только по принуждению сверху..

второе, "настоящие программисты" (ну те, кто так значится по штатному расписанию и кто отвечает головой за код) это дядечки далеко за 40 и они особо баловаться не будут (наши-то записать бинарь во флешку не всегда могут да, например, пишут в кейл 2.х, так как кейл 3.х "не так выглядит")

третье, твоя сборка (или как это назвать, чтобы было верно по-научному) преспокойно собирает ассемблеровский код (было бы удивительно если не собирала) и достаточно простой С-код, осуществляющие чуть больше чем запись/чтение в память и дрыганье ножками

четвёртое, серии кристаллов ведут себя по-разному. "а в этой партии вот то, то и то не реализовано или реализовано криво"(с). кроме того списка "время выпуска / партия"-"ревизия"-"список ошибок" как-то не попадалось

Вы таки думаете что я первый раз замужем? а вот нет! развелся! завязал я со службой государевой. и то что Вы написали сверху для меня не хужлитература а тоска и безнадега в которой 15 лет провел. Всецело понимаю и сочувствую.

 

пятое, будем очень благодарны если будет собираться под вин32 хост с таджетом "сферический" мипс, в котором есть библиотеки как для софтового (чтобы дружило с тем же пик32) так и для железного флоата, так как, в моём случае, на мипсе2 на ~20МГц и полумегабайтами озу и пзу не до фортрана и тем более не до с++

пол мегабайта???? да это вселенная. я больше 64к пока не встречал. однако с успехом использую и фортран и С++. уверяю, то что "С++ это не то что походит к микроконтроллерам" - глубочайшее заблуждение порожденное непонятно чем. я специально пытался это понять но размного ответа не нашел. Вопрос в том что все нужно умело применять.

 

сферический мипс это здорово!

в данной ветке выкладывается одна из сборок специально для юзателей pic32 - такчто уже все "было". в ней софтовая плавучка а для комдива с железной.

 

зы простите нас не_разумных

no comments

 

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

все свежаки которые я собираю - собираются из транка, если всплывают косяки я их по возможности правлю чтоб собралось, потом тестирую в силу возможности и тоже правлю если опятже косяки в кодогенерации. То есть по сути - сборки экспериментальные и могут работать с ошибками. Но сегодня сборка экспеерментальная в квадрате. я потратил время на то чтоб разобратся с 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%)

РАБОТАЕТ!!!!! НО..... что он делает с кодом :wacko: ! я в листингах ваще концы найти не могу. отладчик уходит в астрал и в состоянии только остановить и пустить код далее - ничего более, даже адреса глобальных переменных определить не может. глядя асм видно что функций уже видимо нет! все нахрен так перемешано что там где ранее были переходы из дной функции в другу - их там просто нет - линейный код! полный ахтунг.

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

6, видно что зачемто LTO увеличивает расход ОЗУ, что это косяг или так вынуждено - пока не исследовал. нада файлы мапы памяти смотреть и разбиратся. пожже.

7. есть недостаток но для нас эмбеддеров не существенный - преред линковкой все объектиники загоняются в память и ликер по ним ходит и отимизирует. соответственно слинковать проект объем объектников которо больше чем ОЗУ хост машины - нельзя, правдв идет работа у разработчиков чтоб это кусками можно былобы делать.

8. довольно долго GDB учили понимать отоптимайщеный код - научили. затем очень доло его учили понимать код сгенеренный компиллером C++ (шаблончики, виртуальные методы и конструкторы в сошках и прочая...) типа щас более менее но не всегда цепляестя за код. С LTO видимо будет полная попа - на выходе настолько не то "что вы имели ввиду" что похоже отладчикам ничего не светит даже в отдаленной перспективе. хотя кто знает.... про дебаг неоптимизированного кода я не говорю - считаю актом практически не несущим новой информации в эмбедед.

9. в итоге видим что LTO вещ чумовая и сравнительно новая, неустоявшаяся. но на мой взгляд это реальный идейный прорыв в методах оптимизации. на данный момент все в стадии отработки и вопросов пока больше чем ответов.

 

 

все это можно поробывать в действии - сборка для хоста linux 64bit

http://klen.org/Files/DevTools/linux-x86_6...ld-lto.tar.lzma

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я сначала ошалел - а потом попробывал представить сябя на его месте. и действительно - таблица векторов это тупо массив байтов. он же не знает что это такое. к этому массиву из кода не происходит никаких обращений - значить это мертвое - отрезаем...
Если этот линкер использует скрипты того же формата, что и старый - то достаточно в скрипте обрамить нужные секции в KEEP() и ничего не будет выкидываться без всяких шаманств с фиктивными обращениями. Такое и раньше происходило по --gc-sections.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если этот линкер использует скрипты того же формата, что и старый - то достаточно в скрипте обрамить нужные секции в KEEP() и ничего не будет выкидываться без всяких шаманств с фиктивными обращениями. Такое и раньше происходило по --gc-sections.

в тероии.

а на практике

........
    .text :                                

    {

        _image_start_  = .;

        _vec_start_ = .;

        KEEP(*(.flash_vec_table*))

        _vec_end_ = ALIGN( . , 8);
.......

выкинул структуру с векторами которая укладыватся в секцию flash_vec_table

без lto не выкидывает. еще предстоит понять как скрипт линкера влияет на lto, наверняка что вылезет новое. линкер то другой!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

http://klen.org/Files/DevTools/linux-x86_6...110807.tar.lzma

размер 81Mb

 

openocd стал (насколько мне удалось натестить) хорошо работать с stm32f2xx

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...