Это-ж open source!

Хороши продукты с открытым исходным кодом — бесплатны, свободны, сообщество и всё такое. Да вот ошибки в ни, к сожалению не редкость. Но это-ж open source! Нашел ошибку, исходный код есть — возьми и почини. Сказать легко. Дальше маленькое расследование одной редкой, но неприятной ошибки в пакете binutils для ARM.

Предыстория.

Замечательная фирма STMicroelectronic
Понадобилось мне слинковать одну библиотеку, скомпилированную в IAR for ARM, в проект компилируемый с помощью arm-gcc (конкретно это был RF стек для STM32W108 SimpleMAC о нем расскажу по-позже). На первый взгляд все должно получиться, поскольку и IAR и GCC используют один и тот-же формат объектных файлов, бинариков и библиотек, это ELF. И на него даже есть стандарт , которому компиляторам следует придерживаться. Но как водится одни стандарты интерпретируют по своему, а другие на них местами забивают.

История.

Итак. Собираю я свой проект — он прекрасно линкуется со злосчастной IAR-овской библиотекой. Запускаю, и ничего не работает. При первом-же вызове функции из этой библиотеки, контроллер падает в HardFault где-то глубоко в её недрах. Падает из-за того, что какая-то инструкция пытается прочитать что-то по недопустимому адресу. Блин, откуда же ему взяться этому недопустимому адресу, функции были переданы константные параметры, среди которых нет указателей.
Дисассемблируем.
arm-none-eabi-objdump -h -S my-project.elf >> my-project.lss

Смотрим.
Листинг 1.
08000986 <stmRadioWriteSerialReg>:
 8000986:	b530      	push	{r4, r5, lr}
 8000988:	f8df 3630 	ldr.w	r3, [pc, #1584]	; 8000fbc <??DataTable15_1>
 800098c:	f20f 64dc 	addw	r4, pc, #1756	; 0x6dc
 8000990:	f834 4010 	ldrh.w	r4, [r4, r0, lsl #1]
 8000994:	609c      	str	r4, [r3, #8]
 8000996:	f8df 461e 	ldr.w	r4, [pc, #1566]	; 8000fb6 <??stGetRadioPower+6>
 800099a:	f834 5010 	ldrh.w	r5, [r4, r0, lsl #1] ; <- HardFault couse here
...

Ошибка возникает по адресу 800099a. Там происходит чтение элемента из какого-то массива, r4 — базовай адрес, r0 — смещение, судя по lsl #1 размер элемента — 2 байта. В r0 значение выглядит правильным — относительно небольшое смещение, а вот в r4 какая-то лажа. Он загружается в предыдущей инструкции ldr.w r4, [pc, #1566] и судя по аннотации пытается загружать что-то по адресу 8000fb6, а там находится последняя инструкция функции stGetRadioPower:
Листинг 2.
08000fb0 <stGetRadioPower>:
 8000fb0:	4804      	ldr	r0, [pc, #16]	; (8000fc4 <??DataTable15_3>)
 8000fb2:	f990 0000 	ldrsb.w	r0, [r0]
 8000fb6:	4770      	bx	lr

08000fb8 <??DataTable15>:
 8000fb8:	0698 2000
 ...

Какого, спрашивается, лешего?!!! Сразу после stGetRadioPower находится таблица DataTable15, очевидно оттуда должен загружаться этот адрес, но ldr.w почему-то промахивается на 2 байта. В отладчике видно, что так оно и есть и это не дисассемблер меня обманывает. Если дисассемблировать саму библиотеку:
arm-none-eabi-objdump -h -S simplemac-library.a >> simplemac-library.lss

То видно, что пакостная ldr.w пытается грузить именно из DataTable15:
Листинг 3.
000008b2 <stmRadioWriteSerialReg>:
     8b2:	b530      	push	{r4, r5, lr}
     8b4:       f85f 3004       ldr.w	r3, [pc, #-4]	; ee8 <??DataTable15_1>
     8b8:       f2af 0404       subw	r4, pc, #4
     8bc:       f834 4010       ldrh.w	r4, [r4, r0, lsl #1]
     8c0:       609c            str	r4, [r3, #8]
     8c2:       f85f 4004       ldr.w	r4, [pc, #-4]	; ee4 <??DataTable15>
     8c6:       f834 5010       ldrh.w	r5, [r4, r0, lsl #1]
     тут:       никто не        читает

WTF?
Мало того, если посмотреть все ссылки на DataTable15 адреса около неё, то видно, что в некоторых местах та-же ldr.w попадает куда надо, а в некоторых недолёт на 2 байта.
Листинг 4.
08000978 <stmRadioReadSerialReg>:
 8000978:	f8df 363c 	ldr.w	r3, [pc, #1596]	; 8000fb8 <??DataTable15>
 800097c:	f833 0010 	ldrh.w	r0, [r3, r0, lsl #1]
 8000980:	4010      	ands	r0, r2
 8000982:	40c8      	lsrs	r0, r1
 8000984:	4770      	bx	lr

Тут в инструкции 8000978 попали куда надо. Еще раз WTF? Что делать и самое главное кто виноват? Можно конечно купить IAR, но он сцуко дорогой, зато там всё работает — это крайний вариант.
Гугление показало такой баг в GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54974
По симптомам похоже, если LDR, загружающая данный относительно счетчика команд PC, не выровнена по 4 байтам, то промахиваемся на 2 байта. В листинге 4 видно, что LDR на 8000978 выровнена по 4 байтам и попадает куда нужно, а в листинге 1 инструкция 8000996 не выровнена и с ней проблемы.
Стоп, стоп, стоп… этож баг компилятора, а мы линкуемся с готовой библиотекой, значит убийца — дворецкий виноват линкер. Но в чем именно?
Ага, в листинге 3 в нашей LDR, там она по адресу 8c2, видно, что поле где должно быть смещение нули, значит она ссылается на DataTable15 через таблицу символов и линкер должен выполнять для неё релокацию. Зачем помещать инструкцию дальнобойностью в 4096 байт в таблицы релокации, когда она к тому-же ссылается на данные в той-же секции. Смещение между ними будет всегда постоянным и не изменится после линковки. Назавается эта релокация R_ARM_THM_PC12.
При повторном гуглении находится вот такой баг.
«http://sourceware.org/bugzilla/show_bug.cgi?id=10073
Но он про релокацию R_ARM_THM_PC8 — это используется 16-ти битная LDR инструкция. Ищем в дисассемблерном листинге эту 16-ти битную LDR загружающую что-то относительно PC. И всё тоже самое команда не выровненная по 4-м байтам промахивается на 2 байта. То есть IAR генерирует и R_ARM_THM_PC8 релокации. А binutils их не правильно обрабатыват. В ARM IHI 0044E об этих и некоторых других недальнобойных релокациях написано следующее.
In general the addressing range of these relocations is too small for them to reference external symbols and they are documented here for completeness.
И вообще они не рекомендованы к использованию.
В binutils тогда на R_ARM_THM_PC8 вообще забили и на R_ARM_THM_PC12 тоже. GCC никогда не генерирует эти релокации, GNU assembler тоже отказавается их генерировать:
.text
ldr r0, foo
…
.global
foo:
.dword 0xB16B00B5

GAS ругается, что не поддерживает такую релокацию. А IAR генерирует их почем зря.
Итак исходя из бага по ссылке выше в binutils эти релокации добавили 2009 году, но протестировать видимо забыли. Да и как их протестируешь, если GCC и GAS эти релокации не генерируют — интеграционные тесты не сделаешь, а про модульные тесты в binutils никто не слышал.
Поначалу я не хотел лезть в исходники binutils, а пытался как-то избавиться от ненужных релокаций, выкусить их из таблицы символов, чтоб потом пропатчить библиотеку и воткнуть в проблемные команды нужное смещение. Не получилось, символы, такие как DataTable15, на которые ссылаются проблемные релокации, используются и в нормальных релокациях, чтоб всё это разобрать нужен полноценный линкер…
Пробовал использовать альтернативный линкер из состава binutils — »gold". Он не использует libbfd, на которой основываются все остальные программы из binutils. Он не смог собрать мой проект, падая со внутренней ошибкой.
Оставалось только одно. Нет, не покупать IAR, конечно, а надевать болотные сапоги-говнодавы, брать лопату и лезть разгребать исходники binutils.
Имена проблемных релокаций известны из ARM IHI 0044E — это R_ARM_THM_PC12 и R_ARM_THM_PC8, поэтому надеясь, что авторы binutils не стали для них придумывать для них свои названия делаю полнотекстовый поиск по ним. И бинго, в файле «bfd/elf32-arm.c» искомые имены находятся в виде меток в switch. Там даже коментарий имеется:
/* We do not check for overflow of this reloc.  Although strictly
	   speaking this is incorrect, it appears to be necessary in order
	   to work with IAR generated relocs.  Since GCC and GAS do not
	   generate R_ARM_THM_PC8 relocs, the lack of a check should not be
	   a problem for them.  */

Да вы тут не только «do not check for overflow», вы вообще do not ckeck работает эта штука или нет.
А вот и кусок кода, где это самое смещение в ldr вычисляется:
relocation = value + signed_addend;
	relocation -= (input_section->output_section->vma
		       + input_section->output_offset
		       + rel->r_offset);

Попробуем разобраться что это. Вскрытие показало, что:
value — это конечный адрес символа на который ссылаемся, типа DataTable15 из листинга 2.
signed_addend — это знаковый довесок, который кодируется в инструкции, к которой применяем релокацию, зачем нужен ХЗ, почти всегда равен +/-4 или 0.
input_section->output_section->vma — базовый адрес текущей секции после релокации. С секция у нас .text, базовый адрес 0x08000000. Всё правильно — это начало FLASH в Cortex-m3.
input_section->output_offset — базовый адрес текущей входной секции.
rel->r_offset — смещение текущей инструкции относительно базового адреса текущей входной секции.
Итак, все три слагаемых в скобках есть абсолютный адрес текущей инструкции. Именно с ним и проблемы. Потому, что для, например, LDR r0, [pc, #100] базовый адрес относительно которого происходит загрузка значения из памяти — это не адрес текущей инструкции, а адрес текущей инструкции плюс 4, округленный вниз до кратного 4 (для Thumb режима, для ARM режима +8, а не +4).
relocation = value + signed_addend;
	relocation -= (input_section->output_section->vma
		       + input_section->output_offset
		       + rel->r_offset) & ~3;

Вот! У значения в скобках надо было только обнулить два младших бита. 5 символов из которых 2 пробела. И так в двух местах, для R_ARM_THM_PC12 и R_ARM_THM_PC8.
После собираем binutils командами:
../configure --prefix=/usr/local/arm --target=arm-none-eabi --enable-interwork --enable-multilib --disable-nls --disable-libssp --program-prefix=arm-none-eabi- --with-sysroot
make all install -j 4

Компилируем свой проект со вновь собранным линкером и, о чудо, он работает!

Интересно, почему об этой ошибке нет практически никакой информации в сети. Неужели никто не пытался линковать библиотеки скомпилированные в IAR для ARM с помощью GNU toolchain? В любом случае теперь это работает.
Архив с починенным линкером большой — к топику не прикрепляется, поэтому ссылка на Dropbox.
  • +18
  • 30 марта 2013, 00:22
  • neiver

Комментарии (85)

RSS свернуть / развернуть
поздравляю с успешным решением проблемы. Таким глубоким знаниям и пониманию сути проблемы можно только позавидовать
0
Поздравляю! Осталось патч отправить мейнтейнерам, в лучших традициях опенсорс :)
+2
  • avatar
  • evsi
  • 30 марта 2013, 04:44
+1
0
Классно! В апстрим патч отправили?
0
Патч — пока нет. Скоро.
0
патч за секунду можно сделать через (пишу на память, перепроверьте на всяк случай)
$ diff -urN dir_or_file_prev dir_or_file_new > file.patch
0
Я обычно не мудрствую лукаво:
cd source-dir; diff -c ./aaa/file.orig ./aaa/file | gzip -9 > patch-for-aaa.diff.gz

:)
0
Просто так как я писал он хавается как самый классический патчик, хотя таких способов может быть несколько :)
Скажите, вашим способом в результате принимается файл тулзой patch нормально?
0
zcat patches/patch-for-aaa.diff.gz | patch -p1 --verbose

Запросто.
0
Интересно, ясно.
я просто по привычке делал всегда как указывал, надо будет попробовать ключик -с ;)
0
С ключом -c патч становится гораздо читабельнее, попробуйте. Кроме того, раз присутствует context, patch может наложить патч даже если пара строк в исходном файле съехала.
0
Добавлю, очень часто с ключом -c делать патч удобно, когда изменяется только один файл, а не несколько — не тратится время на сравнение всех файлов в каталогах с оригиналом и с измененными файлами.
0
УФ ) Чуть мозге себе не сломал :)
0
Мозг
0
Да, автор — точно MegaMind, а я тоже break minde
0
Круто! Все-таки в случае с проприетарщиной взять и исправить ошибку было бы нельзя :) А то, что «IAR дорогой, но там все работает» — это не показатель, ошибки и там могут быть. Человеческий фактор от типа лицензии не зависит…
0
  • avatar
  • yars
  • 30 марта 2013, 11:10
Там обычно подход другой — «че за хрень? (листинг прилагается)» в техподдержку.
0
Ну это да, сам пару раз так выступал :)
0
Только в моем случае это были услуги, а не код.
0
Кстати, а адресок, на который в IAR по этому поводу писать, не знает ли кто?
Я нашел мелкий, но мерзкий баг, причём стабильный и проявляется в трёх версиях, включая последнюю.
На сайте у них не нашел адреса, а имеющаяся форма запросов вроде как не очень подходит…
0
Благодарю, но это я знаю. Я имел в виду какой-то спец-адрес электронной почты для извещения о найденых багах. Там нужно не только текст, но и ещё картинки добавить, а в их форму картинки не очень дырятся :)
Но, всё равно, спасибо.
0
Не за что :)
0
тут: никто не читает
Цвет палевный)
Зачем помещать инструкцию дальнобойностью в 4096 байт в таблицы релокации, когда она к тому-же ссылается на данные в той-же секции.
Может, у иара секции не неизменные? Например, если смартлинкер умеет выкидывать из них неиспользуемые функции, то может потребоваться перемещение данных внутри секции.
(для Thumb режима, для ARM режима +8, а не +4).
+ rel->r_offset) & ~3;
А эта ошибка потом не вылезет с ARM режимом?
0
  • avatar
  • Vga
  • 30 марта 2013, 11:14
А эта ошибка потом не вылезет с ARM режимом?

Нет. Эта релокация исключительно для Thumb.
0
очень замечательная статья, приятно когда не боятся надевать «болотные сапоги-говнодавы и брать лопату»! я прочитал комментарии по ссылке Your text to link... и нашел, что Nick Clifton сделал патч к исходнику elf32-arm.c_patch.2, в нем указано следующее:

        value = abs (relocation);
 
 	/* We do not check for overflow of this reloc.  Although strictly
 	   speaking this is incorrect, it appears to be necessary in order
 	   to work with IAR generated relocs.  Since GCC and GAS do not
 	   generate R_ARM_THM_PC8 relocs, the lack of a check should not be
 	   a problem for them.  */
 	value &= 0x3fc;  

это не является тем, что Вы сделали? обнулили младшие 2 разряда?
0
Нет. Обнулять надо именно два младших разряда базового адреса изменяемой инструкции. value — это адрес цели для этой инструкции. Его тоже в некоторых случаях округлять.
0
то что нашли баг, это хорошо и главное нужно, и превосходно если этот патч вы отправите в багрепорт гцц, с переводом всего написанного тут на инглиш, той части текста где вы детектили в чем ошибка и как найти. Тигих расследований и поисков приведений еще на http://electronix.ru всегда было куча, я тоже в начале 200х искал приведения гцц на ARM7TDMI, и зачастую оказывалось что можно в своем коде, если правильно писать всего этого избегать. То есть трабла с компиллерами и их тулзами есть всегда. и это не потомучто гцц опенсоурс. а потому что реально трудно даже олдовым компиллеромейкерам писать все без косяков независимо от фирмы производителя.
… И есть несколько моментов
— вы уверены что это не исправлено в последней версии гцц?
— может это был не верно слинкован иаровский объект?
— может у вас не все структуры и юнионы выровняны, битовые поля не все указаны и иззаэтого компиллер всталяет всякие чудеса итд
Все равно вы молодец, и полученный вами опыт вам бы не помешало отправить в саппорт гцц. Это будет для вас еще один опыт веселый, я такое уже в 200х годах проходил ;) порой они выносят мозги изрядней чем весь найденный вами баг. ;)
0
Баг таки не в GCC, а в binutils, конкретно в libbfd. Да в крайней binutils-2.23.2 он не починен.
А как библиотеку можно не правильно слинковать? Секции .text, .data, .bss, .rodata и еще некоторые специфичные для данной библиотеки находятся в правильных адресах, что еще нужно?
0
ну раз не починен то определённо стоит патч отправить им. ;)
Если библиотека была собрана в иаре с косяком, вот что еще может быть. я после того как пару раз переносил проект с аира на гцц уже в этом не сомниваюсь. Иаровцы позволяют себе разные свистоперделки использовать в своем компиляторе, и не исключено что они могли накосячить. И получится что вы воевали с мельницей.
0
раскрыть комментарий
-8
Знали бы вы, сколько я встречал багов в закрытых компиляторах (не под ARM)… И единственный способ — -переписывать код что бы его не провоцировать и ждать в лучшем случае пол-года…

Вообще, средства разработки должны быть открытыми — потому что иначе им просто нет веры. А баги встречаются и там и там в совершенно равной степени, никто не бзегрешен. Только в OSS обычно правятся быстрее.
0
знаем, канпелировали, но как выше заметил uschema — большинство шишек набивают изза шила в жо, а не по счастливой случайности
0
Именно так. Глупая картинка выше как раз в тему проприетарного софта)
Я встречал ранее баги у Keil и довольно волокитно туда обращаться видимо если вся организация предпочитала дальше жрать кактус, просто учитывая где «не верить» и чего делать в нём не следует.
Вообще же время реакции на баг у проприетарщиков может быть значительно дольше.
0
стопудова
0
У закрытого софта порой не дождешся фикса, а если он и появится то породит новые, потому что то что делало обход старого бага, теперь не прокатит ).
Я на днях у тексас-инструментса нашел открытый документ в котором они обозначили состояние совместимости их компиллера под ихнее же с2000 ядро (щас с ними работаю), так после ознакомления этого документа вообще всё укладывается на свои места и становится откровенно очевидно что в компиллере косяков еще мильен, то-то я и перестал удивляться что очевидный код не компилится под tms320, в то время как этот же код я юзал под прошлой версий компиллера. Приходится делать всякие не кравимые извращения, а бы оно скомпилилось и работало ;)
Так что учитывая все вышесказанное я более чем сотый раз заверяю, в софте с открытыми исходниками состояние дел на порядок яснее и очевидней, и фиксится быстрее если не конторой то людьми.
Так что картинка ни разу не в тему!
0
ну дык положи нах те с2к, шо мало других дсп? все ваши проблемы высосаны из пальца, и решаются при необходимости очень просто
0
ха, если б от меня зависило, так бы и сделал ;) В моем случае уже заложены задолго до меня )
Но тут речь про арм и гцц, и я писал о том что «ваши кактусы» это как раз для проприетарных компилеров. Примите реальность как она есть ;)
0
я писал не про Гы ЦеЦе в частности а за весь опенсорц, а если у вас заложено — так продолжайте жрать ;)
-1
вы хотите поговорить про опенсорс? не охото. но, ок. давайте…
Любой продукт опенсорса развивается намного качественее, и более того даже срок жизни проекта намного дольше, так как когда закрытый софт перестал развиваться, то все, точка. В случае с опенсорсом он всегда имеет шанс на развитие и как правило когда это происходит то развивается намного активнее, быстрее и качественее.
Так что боюсь что ваша неспособность понять эту очевидность граничит с неграмотностью в этом вопросе. Я даже не буду вам называть имен проектов с открытым кодом которые просто кипят своим прогрессом и уделывают конкурентов с лагеря проприетпрщины. Но, обсуждая все это мы зайдем в дремучий лес флейма. Будем продолжать или вы сразу признаете неправоту ваших высказываний? Или пусть каждый останется с своей (не)правотой наедине, не разводя флейм? Вот чесно, мне не охота на это тратить время, ровно как и пофиг на ваши мнения. Почитайте чтоли, погуглите.
0
Любой продукт опенсорса развивается намного...
сплошное обобщение
Я даже не буду вам называть имен проектов
+ попытка спрыгнуть от конкретики
Вот чесно, мне не охота на это тратить время, ровно как и пофиг на ваши мнения. Почитайте чтоли, погуглите.
сходите чтоли, наху свой усчема.ком и вещайте свою ересь там, если вам тут на нас пофиг, да ;)
-2
увы, вы безнадёжны.
+2
Можно его(C2K) юзать на asm легко — все эти циклы фильтров или FFT довольно примитивны и обсосаны уже давно, но если юзать его, как обычный MCU, да еще возможно с GUI… и учитывая, что FreeRTOS порта для него нет — то да, — начальство знает толк в извращениях. Тот же хваленый его ADC можно было бы заменить на дешевый внешний, но с большим MSPS.
0
FreeRTOS нет? вы смеётесь? Видно что вы не копали эту тему, ок, пару слов скажу.
Есть, точнее его форк. И более того развивается от ТИ по полной, называется SYS/BIOS (бывший DSP/BIOS), и судя по отзывам он намного лучше FreeRTOS. Сам я его не юзал(хоть и было желание), но начитался изрядно.
www.ti.com/tool/sysbios&DCMP=sysbios&HQS=Other+OT+sysbios
en.wikipedia.org/wiki/SYS/BIOS
0
Неплохой opensource а-ля TI и только для TI: порты от msp430 до OMAP35xx ARM Cortex-A8. Только видимо многие здесь(и я) в первый раз слышат про эту RTOS. У Keil тоже есть RTX RTOS, тоже royalty-free + source code, только что-то мало про нее слышно.
0
ну я думаю что вы не слышали лишь потому что ихний форк они развивают только для их чипов, что толично. было б странно если б они делали поддержу например стмок, согласны? ;)
И вторя причина почему вы не слышали, скорее всего — потому что не интересовались ихними дсп или темой операционок для дсп.
0
FreeRTOS нет? вы смеётесь? Видно что вы не копали эту тему, ок, пару слов скажу. Есть, точнее его форк. И более того развивается от ТИ по полной, называется SYS/BIOS (бывший DSP/BIOS), и судя по отзывам он намного лучше FreeRTOS.
Итоговое резюме:

Если разговор о чипах TI с архитектурой C2K(устар.), то у TI давно очень были куски RTOS в виде этого SYS(DSP)/BIOS(который у них с 1985г. и естественно не является форком FreeRTOS) + кучи отдельных библиотек(TCP/IP, FAT_fs и т.п.).

Сейчас они это все свалили в одну кучу, причесали под портирование на всю свою номенклатуру чипов(от MSP430 и C2K до ARM Cortex) и пиарят как некую TI-RTOS.

FreeRTOS поддерживает MSP430 и ARM Cortex TI чипы, но не поддерживает, например, C2K.

Политика TI похоже такова: юзайте royalty-free наш «opensource», но на наших чипах only и… и без всякого стороннего «true opensource»(который они называют вирусным) в проекте, в котором используется наш «opensource». Т.е. мухи и котлеты отдельно — не заражайте наш «opensource» вирусом бесплатности Столмена.

Вот собственно что они и пишут во всех исходниках:
Copyright (C) 2005-2012 Texas Instruments Incorporated. All rights reserved.
# Software License Agreement
#
# Texas Instruments (TI) is supplying this software for use solely and
# exclusively on TI's microcontroller products. The software is owned by
# TI and/or its suppliers, and is protected under applicable copyright
# laws. You may not combine this software with «viral» open-source
# software in order to form a larger program.
0
RTX RTOS, тоже royalty-free + source code
Разве исходники кейл выложил в открытый доступ?
0
source code — это не open source
0
Как раз наоборот — source code — это и есть open source
Но open source это не означает бесплатно.
0
Я имел в виду, что в упаковке RTX есть подкаталог \SRC со всеми исходниками и есть еще файл license.txt
0
Нет, почему же. Полным-полно проприетарных библиотек, поставляемых с исходниками. Да хоть те же игровые движки. Сорцы купить можно, а распространять — нет, да и модифицировать — только в интересах своего проекта.
0
opensource — это очень хорошо. Вот например: некто установил наворочанный сервер c кучей ПО и прожужжал заказчику уши про открытость и особенно бесплатность, а потом срубил с него $1000 или $2000. Очень выгодная вещь, и этим надо пользоваться, но человек должен быть всесторонне развит — не надо рефлексировать, но надо честно пользоватся и продукцией пиратов себе во благо.
0
Ну вообще то нужно понимать про разницу между — услуги, бесплатность и открытость, это разные вещи.
Если бы софт стоил 1000 он что с заказчика бы взял 0 за настройку? нет конечно, взял бы все те же 1000.
0
Какая разница, речь о том, что кто-то по факту работает бесплатно, а кто-то делает на этом деньги(хотя бы тем, что получает бесплатный продукт, т.е. не платит за чью-то работу).
0
та я понял что вы имели ввиду ;)
дополнил мысль )
0
В современных условиях бесплатный opensource нужен для того, чтобы проприетарщики делали хороший продукт. Но проприетарщики тоже не дураки — зачем что-то делать, когда можно наваривать бабло на бесплатном opensource. Где-то Столмен все же что-то не учел, как и марксисты… В любом случае — человек должен получать плату за свой честный труд, это постулат, против которого ничего не имеют ни марксисты, ни капиталисты. Только вот сколько — в этом весь вопрос.
0
Можно конечно купить IAR, но он сцуко дорогой, зато там всё работает — это крайний вариант.
Тут только мне IAR EWARM подарил? ;)
0
  • avatar
  • DVF
  • 30 марта 2013, 20:41
Это версию с ограничением на размер кода 32 Кб?
0
когдато бил-гейтс говорил что 64к это огогого сколько, и миру больше просто не нужно ))
так что 32к это всежтаки, как ни крути, половина от огогого ))))
0
он говорил про 640к, а потом сказал, что эти слова его самая большая глупость )
0
а, ну значит подзабылось и перепутал %)
0
А не 640?
0
Да нет. Дарят с лекарством от головной боли.
0
Во многих организациях это сейчас категорически неприемлимо. Требуется лицензионная чистота.
0
С этим не поспоришь. Но как сказал мне один знакомый разработчик в беседе на похожую тему, он не пошел бы работать в компанию, которая не может себе позволить лицензию от IAR. Вероятно, имелись ввиду серьезность предприятия и уровень зп.
0
Он, конечне ж, прав. Но экономическая отсталость страны даёт о себе знать особенно в Немоскве. И когда общий бюджет проекта около миллиона рублей, IAR со своими 3.5 евро за лицензию (а их надо минимум две) составляет уж больно весомый процент.
0
а их надо минимум две
Почему две? По числу программистов?
IAR со своими 3.5 евро
Вроде были у них варианты от 1000 евро.Или их недостаточно?
0
Скорее по количеству продуктов )
0
Для АРВ и для АРМ?
0
типа того ) в нашем случае арм и авр, потому как на платах были как те, так и те, что часто случается, когда сложное что то… а контора серьезная — нужна лицуха…
0
А что, на каждый проект — новый IAR?
0
Нет, на каждого разработчика — лицензия. На других проектах IAR не используется.
0
А когда предприятие из десятка человек то видимо о лицензии и речи быть не может.
А я работал бывало где общая ЗП менее 1/2 млн в месяц (по 10-15 тыр на человека + по 60 дирекции) а вот софта там было на ооочень много денег, разумеется не купленного.
0
  • avatar
  • Ross
  • 01 апреля 2013, 17:39
А я думаю, наоборот, чем меньше контора, тем боязнее должно быть пользоваться ворованным.
Потому как миллионные штрафы могут стать просто фатальными, а если не заплатишь, то ещё и уголовщину пришьют
0
Кому они сдались. Если бы не безнал, то можно было бы и налоги не платить :)
0
всё хорошо, только в начале статьи не сказано, в чём проблема.
Про «одну» библиотеку тоже непонятно.
Потом, ELF — это хорошо, но есть ещё такя штука, как ABI, который у компилеров может быть разный.
Вобщем, ощущение от статьи примерно такое: ХЗ в чём именно косяк, но подправим тут 2 байта — и всё заработает.
0
Не знаю все вроде понятно было. и ABI должен быть одинаковый так-как это более мене стандартизованная вещь.
0
ABI вероятно тоже проверен, ну и сейчас для этих тулчейнов стандарт — EABI. Ну и на крайний случай, всегда можно прилепить ABI-переходники на асме.
В чем косяк — как раз понятно. Линкер от GCC (точнее, binutils) неправильно обрабатывает некоторые релокации. GCC их не использует (потому и толком не отлажено), а вот IAR — еще как, поэтому при линковке программы на GCC с объектником из IAR получается каша.
0
Да вы молодцы что докопались в «сапогах» )
А скажите компилировали вы тулчайеы под Linux-ом?
0
Не, под Windows с помощью Mingw. Под Linux даже проще.
0
Очень похвально, что автор докопался до сути и разрешил проблему, а не пошел по пути использования леченого ИАРа. Надеюсь выпустите патч.
0
Это время даром — то можно и копаться. Но проще взять Keil ломаный и без гем--я сделать всё. Вот когда исходников нет — это сложнее — приходится тоже мозг напрягать.
0
О каких исходниках идет речь?
0
Подозреваю, что компилятора/линкёра и прочей фигни
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.