Jump to content

    

Rust вместо C

1 час назад, AlexandrY сказал:

Думал эта дурь только в Keil-е есть, но теперь и до IAR-а добралась.

Подозреваю, что это не дурь :), а следствие "parallel build", когда IAR ради ускорения процесса компиляции компилирует все модули проекта одновременно, разбрасывая их по разным потокам, в надежде, что у пользователя стоит многоядерный процессор. А поскольку разные потоки могут завершаться в разное время, то из-за этого может нарушаться порядок линкования их объектников, если линкер их линкует в порядке готовности. Раньше IAR режим "parallel build" не поддерживал, а потому и объектники линковались всегда в одном и том же порядке.

 

Однако это лишь мои подозрения, которые вы можете подтвердить или опровергнуть так:

Сходите  в "IDE Options" (меню Tools -> Options...) и снимите там галочку с пункта "Enable parallel build", чтобы запретить его. Компилировать станет чуть дольше, но появится надежда на воспроизводимость результата.

Share this post


Link to post
Share on other sites
23 минуты назад, Xenia сказал:

А поскольку разные потоки могут завершаться в разное время, то из-за этого может нарушаться порядок линкования их объектников, если линкер их линкует в порядке готовности.

Невозможно компоновать пока все исходники не скомпилены. Так как тогда не получится обработать таблицы импорта/экспорта объектных файлов. Компоновщик должен запускаться в одном потоке, после готовности всех .obj.

Share this post


Link to post
Share on other sites
16 минут назад, jcxz сказал:

Невозможно компоновать пока все исходники не скомпилены. Так как тогда не получится обработать таблицы импорта/экспорта объектных файлов. Компоновщик должен запускаться в одном потоке, после готовности всех .obj.

Ваше замечание резонно. Однако и компоновщик тоже может быть реализован в духе "parallel build" :).

Просто у меня нет других гипотез по поводу того, что еще могло измениться в IAR'е с тех пор. Тогда как "parallel build" - одна из последних новинок :). Вот я ее и заподозрила.

Share this post


Link to post
Share on other sites
6 минут назад, Xenia сказал:

Ваше замечание резонно. Однако и компоновщик тоже может быть реализован в духе "parallel build" :).

Это вряд-ли. Ибо - не имеет смысла. Выигрыша не будет.

Цитата

Просто у меня нет других гипотез по поводу того, что еще могло измениться в IAR'е с тех пор. Тогда как "parallel build" - одна из последних новинок :).

То что у AlexandrY получаются разные .bin - так это видимо ему нужно благодарить те "библиотеки", кои он натаскал себе в проект. Возможно они что-то тащут зависимое от путей. Или в бинарнике присутствует отладочная инфа.

Правильное преобразование .out -> .bin в IAR делается: $EW_DIR$\arm\bin\ielftool.exe --bin --strip $TARGET_PATH$ $TARGET_BPATH$.bin

(обратить внимание на ключ "--strip").

В этом случае (скомпилял только что свой проект с разными путями) всё должно быть байт-в-байт. Что и подтверждается:

B:\WORK.SRC\FLASH_RELEASE.OUT\EXE\>fc /b D:\WORK\INVERTOR\WORK.SRC\FLASH_RELEASE.OUT\EXE\work.bin B:\WORK.SRC\FLASH_RELEASE.OUT\EXE\work.bin
                                                                                                                                            
Сравнение файлов D:\WORK\INVERTOR\WORK.SRC\FLASH_RELEASE.OUT\EXE\work.bin и B:\WORK.SRC\FLASH_RELEASE.OUT\EXE\WORK.BIN                      
00000020: B4 39                                                                                                                             
00000021: 63 AF                                                                                                                             
00000022: B3 01                                                                                                                             
00000023: FB 86                                                                                                                             
00000216: 33 35                                                                                                                             
00000218: 31 30                                                                                                                             
00000219: 38 30                                                                                                                             

Как видно - различия только в байтах 0x216...0x219 (туда у меня сохраняется время компиляции - __TIME__) и в 0x20...0x23 - здесь находится CRC образа прошивки (в таблице векторов). Других отличий нет.

Share this post


Link to post
Share on other sites
1 hour ago, Xenia said:

Подозреваю, что это не дурь :), а следствие "parallel build", когда IAR ради ускорения процесса компиляции компилирует все модули проекта одновременно, разбрасывая их по разным потокам, в надежде, что у пользователя стоит многоядерный процессор. А поскольку разные потоки могут завершаться в разное время, то из-за этого может нарушаться порядок линкования их объектников, если линкер их линкует в порядке готовности. Раньше IAR режим "parallel build" не поддерживал, а потому и объектники линковались всегда в одном и том же порядке.

 

Однако это лишь мои подозрения, которые вы можете подтвердить или опровергнуть так:

Сходите  в "IDE Options" (меню Tools -> Options...) и снимите там галочку с пункта "Enable parallel build", чтобы запретить его. Компилировать станет чуть дольше, но появится надежда на воспроизводимость результата.

Ну неет, про параллельную компиляцию я конечно знаю, потому что смотрю на эту галку каждый день. 
Мои проекты настолько сложные, что IAR всегда выкидывает ошибку когда пытается параллельно их компилить, поэтому я даже не пытаюсь включать эту фичу в последнее время.
Отладочную инфу в бинарники не включал никогда и не включаю, даже не знаю как это. Отладочная инфа идет в elf-ах, а не в бинарниках.
Попадание дат компиляции в бинарник интересная версия, поэтому я проверял компиляцию одного и того же проекта из одной и той же директории в разное время. И бинарник был почти идентичный. 
Кстати, когда говорю что бинарники разные , то они реально абсолютно разные, а не кое в каких байтах. 

Ладно, даю подсказку - в разных директориях получается разный файл зависимостей .dep  Сильно разный. 
Но напомню, что директории проектов клонированы один в один. 

Share this post


Link to post
Share on other sites
1 час назад, AlexandrY сказал:

Ладно, даю подсказку - в разных директориях получается разный файл зависимостей .dep  Сильно разный. 

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

 

3 часа назад, jcxz сказал:

Невозможно компоновать пока все исходники не скомпилены. Так как тогда не получится обработать таблицы импорта/экспорта объектных файлов. Компоновщик должен запускаться в одном потоке, после готовности всех .obj.

gold и lld могут работать в многопоточном режиме: https://lld.llvm.org/

Share this post


Link to post
Share on other sites
12 hours ago, AlexandrY said:

Попадание дат компиляции в бинарник интересная версия

Для этого нужно ручками объявить константу, хранящуюся в неиспользуемом месте векторов прерываний, и воткнуть туда __DATE__ и __TIME__.

12 hours ago, AlexandrY said:

Кстати, когда говорю что бинарники разные , то они реально абсолютно разные

Я тоже на такой косяк с gcc нарывался. Так и не понял, что за шняга. Сначала грешил на ccache, но это вроде только к сборке пакетов отношение имеет. У меня прикол был в том, что если сделать с нуля make release, а потом сделать make clean и make debug, после чего опять make clean и make release, то бинарники в первом и последнем случае каким-то чертом иногда бывают разные.

Теоретически линкеру наплевать, в каком порядке ему объектные файлы подсовывают. С другой стороны - он же их начала выравнивает, но это только на 0..3 байта может изменить размер прошивки.

Edited by Eddy_Em

Share this post


Link to post
Share on other sites
4 minutes ago, Eddy_Em said:

хранящуюся в неиспользуемом месте векторов прерываний,

Зачем так? В "пустой вектор" лучше воткнуть обработчик по-умолчанию. Так вы получается отладочное средство. Если этот обработчик сработает, то это будет значить: какая-то странная авария микроконтроллера, или то, что вы переехали на другой МК, и не заметили, что включили неиспользуемую периферию. А константу с датой и временем вообще разместить в любом месте, либо в секции, определённой в скрипте линкера.

Share this post


Link to post
Share on other sites
3 часа назад, Eddy_Em сказал:

Я тоже на такой косяк с gcc нарывался. Так и не понял, что за шняга. Сначала грешил на ccache, но это вроде только к сборке пакетов отношение имеет. У меня прикол был в том, что если сделать с нуля make release, а потом сделать make clean и make debug, после чего опять make clean и make release, то бинарники в первом и последнем случае каким-то чертом иногда бывают разные.

Это - удел всех любителей "библиотек" и чужого быдлокода. Гадать как оно так получилось и что откуда взялось.  :wink:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now