IBAH (29.07.2023 12:59, просмотров: 106) ответил 0men на причина именно в коде, просто в кейле другая оптимизация, она
допускает промахи как и яровская на низких уровнях-
- Например, компилятор может неожиданно реагировать на Undefined
Behavior. Своими глазами видел, как компилятор применял чудесатую
оптимизацию адресной арифметики, потому что по каким-то
соображениям диапазон входных значений был ограничен. Когда в жизни
встречалось другое значение, арифметика вычисляла дикий адрес, и
вот тебе HardFault. А другой компилятор может этого не делать, и
твой косяк останется незамеченным. И да, это именно косяк в
исходнике. - SciFi(30.07.2023 14:55)
- МК под рукой нет. Попробовал статический анализ все ок. Может я
недостаточно точно выразился: ИАР компилирует проект с файлами под
STM32F107 как КортексМ3 (не работает, ХардФалаут), а Кейл
компилирует проект с файлами под STM32F107 как GD32F107(все
работает). Что отличает GD32F107 от стандартного Кортекса? - IBAH(30.07.2023 15:33)
- на днях лечил в проекте на Keil для Nuvoton M2354 (Cortex-M23)
улеты в hardfault, проявившиеся при ненулевом уровне оптимизации.
не стеснялся, с отладчиком поглядел, адреса нечетные увидел,
вспомнил, что низзя так. правда лень было затягивать
cmsis_compiler.h для использования богомерзкого __ALIGNED(x) (не
одним Keil пользуюсь) - тупо виновников, которые массивы uint8_t и
проталкивались в функцию через void* и приводились там к
чему-ни-попадя, связал в union-ы c массивами Vit(150 знак., 30.07.2023 15:53, ссылка)
- Ну если void* приводился к char* на М0, то на компилятор странно
обижаться. Хотя об М23 я был лучшего мнения. - Andreas(30.07.2023 19:24)
- Приводить void* к char* вполне кошерно и даже халяльно. Вот
наоборот - может выстрелить неожиданно. - LightElf(30.07.2023 20:04)
- просто к хорошему быстро привыкают... а плохому быстро учатся:) - Vit(30.07.2023 20:43)
- Хм, возможно. После тестирования разных сортов медовухи могу и перепутать )) - Andreas(30.07.2023 20:10)
- Приводить void* к char* вполне кошерно и даже халяльно. Вот
наоборот - может выстрелить неожиданно. - LightElf(30.07.2023 20:04)
- Ну если void* приводился к char* на М0, то на компилятор странно
обижаться. Хотя об М23 я был лучшего мнения. - Andreas(30.07.2023 19:24)
- на днях лечил в проекте на Keil для Nuvoton M2354 (Cortex-M23)
улеты в hardfault, проявившиеся при ненулевом уровне оптимизации.
не стеснялся, с отладчиком поглядел, адреса нечетные увидел,
вспомнил, что низзя так. правда лень было затягивать
cmsis_compiler.h для использования богомерзкого __ALIGNED(x) (не
одним Keil пользуюсь) - тупо виновников, которые массивы uint8_t и
проталкивались в функцию через void* и приводились там к
чему-ни-попадя, связал в union-ы c массивами Vit(150 знак., 30.07.2023 15:53, ссылка)
- МК под рукой нет. Попробовал статический анализ все ок. Может я
недостаточно точно выразился: ИАР компилирует проект с файлами под
STM32F107 как КортексМ3 (не работает, ХардФалаут), а Кейл
компилирует проект с файлами под STM32F107 как GD32F107(все
работает). Что отличает GD32F107 от стандартного Кортекса? - IBAH(30.07.2023 15:33)
- Нет такого вопроса, это у тебя в голове какой-то пробел. HardFault
вызывает какая-то АССЕМБЛЕРНАЯ инструкция, выполняемая в нетипичных
условиях с нетипичными значениями. Никто не обещает, что разные
компиляторы Кейл и ЙАР должны генерить одинаковый код. А источник
проблемы все равно - в исходнике на Си. Самый распространенный
случай - невыровненный доступ к памяти, который возникает из-за
преобразования типов указателя. У Cortex-M3 есть инструкции,
которые могут выполняться il-2(411 знак., 30.07.2023 10:34)
- Спасибо за развернутый ответ. "Ты ему разрешил". Так вот в этом и
вопрос, где в настройках компилятора это разрешается? Может я
недостаточно точно выразился: ИАР компилирует проект с файлами под
STM32F107 как КортексМ3 (не работает, ХардФалаут), а Кейл компилирует проект с файлами под STM32F107 как GD32F107(все
работает). Резонный вопрос, где в настройках то что отличает GD32F107 от стандартного Кортекса? - IBAH(30.07.2023 14:37)
- Что ты прицепился к компилятору и его настройкам. Я просто в кач-ве
примера привел как
тыпрограммист может добиться невыровненного доступа к памяти: il-2(210 знак., 30.07.2023 15:38)- после такого приходится привыкать к memcpy :) - Vit(30.07.2023 15:59)
- memcpy тоже иногда лажает. Помнится с fk0 срались тут на эту тему. - LightElf(30.07.2023 20:07)
- Кстати да. У себя, при высокой оптимизации ARM GCC, видел, как
байтовый memcpy(), по факту, становится двухсловным. Просто потому,
что шла работа с массивом 32-битных значений. Nikolay_Po(373 знак., 30.07.2023 23:45)
- Как я понял, компилер пытается подложить самую оптимальную версию
memcpy основываясь на своём представлении о прекрасном. И иногда
эвристика слишком оптимистична. - LightElf(31.07.2023 00:14)
- Если не забыть расставить volatile, где требуется, проблем не
будет. Просто компиляторы становятся более совершенными и
оптимизируют больше, чем программист мог себе это представить, но
не больше, чем позволяет выбранный стандарт. - Nikolay_Po(31.07.2023 00:45)
- Не, там не в volatile дело было. Там именно компилятор терял
информацию о типе и делал неверные предположения о выровненности
указателя. LightElf(141 знак., 31.07.2023 01:14)
- "...компилятор терял информацию о типе и делал неверные
предположения о выровненности указателя" - думаю, что именно из-за
того, что указатель был слишком изменчив (слишком волатилен), за
пределами контекста секции кода. Nikolay_Po(27 знак., 31.07.2023 07:47)
- volatile - это совсем не про это - SciFi(31.07.2023 07:50)
- Не удивлюсь, что про всё. Оптимизации случаются весьма и весьма изощрённые. Если, в контексте, обычный указатель меняется только с шагом двойного слова, то компилятор имеет право считать указатель выровненным. И, если программист, не объявив указатель volatile, вне контекста, прирастит эту переменную на байт - жди беды. - Nikolay_Po(31.07.2023 07:54)
- volatile - это совсем не про это - SciFi(31.07.2023 07:50)
- "...компилятор терял информацию о типе и делал неверные
предположения о выровненности указателя" - думаю, что именно из-за
того, что указатель был слишком изменчив (слишком волатилен), за
пределами контекста секции кода. Nikolay_Po(27 знак., 31.07.2023 07:47)
- Не, там не в volatile дело было. Там именно компилятор терял
информацию о типе и делал неверные предположения о выровненности
указателя. LightElf(141 знак., 31.07.2023 01:14)
- Если не забыть расставить volatile, где требуется, проблем не
будет. Просто компиляторы становятся более совершенными и
оптимизируют больше, чем программист мог себе это представить, но
не больше, чем позволяет выбранный стандарт. - Nikolay_Po(31.07.2023 00:45)
- Как я понял, компилер пытается подложить самую оптимальную версию
memcpy основываясь на своём представлении о прекрасном. И иногда
эвристика слишком оптимистична. - LightElf(31.07.2023 00:14)
- обычно оно должно быть вылизано и оптимизировано. если такое подводит, то либо закат Солнца вручную, либо закидывать такой компилер подальше - Vit(30.07.2023 20:47)
- Кстати да. У себя, при высокой оптимизации ARM GCC, видел, как
байтовый memcpy(), по факту, становится двухсловным. Просто потому,
что шла работа с массивом 32-битных значений. Nikolay_Po(373 знак., 30.07.2023 23:45)
- memcpy тоже иногда лажает. Помнится с fk0 срались тут на эту тему. - LightElf(30.07.2023 20:07)
- после такого приходится привыкать к memcpy :) - Vit(30.07.2023 15:59)
- Что ты прицепился к компилятору и его настройкам. Я просто в кач-ве
примера привел как
- На прошлой неделе нарвались, дело не в софте а в харде было, там 2
блока 19" и на дин рейке кое что. Несколько преобразователей с
развязкой. Драйверы которые раньше ставили пропали, на транзисторах
сделал, они вдвое больше жрут. И IRM03-12 стала вырубаться через
пару секунд. - Visitor(30.07.2023 10:53)
- Да понятно оно, что HardFault может произойти от чего угодно.
Человек недоумевает, почему на одном компиляторе есть HF, а на
другом нет. - il-2(30.07.2023 11:09)
- Логично, но и тут сову на глобус натянуть можно: допустим в одном
компиляторе время инициализации вдвое больше чем в другом, бред,
конечно, но разного насмотрелся:-) - Visitor(30.07.2023 11:18)
- О! На баг с разницей по времени инициализации и я попадал, ешё с PIC24F. - Nikolay_Po(30.07.2023 23:47)
- Логично, но и тут сову на глобус натянуть можно: допустим в одном
компиляторе время инициализации вдвое больше чем в другом, бред,
конечно, но разного насмотрелся:-) - Visitor(30.07.2023 11:18)
- Да понятно оно, что HardFault может произойти от чего угодно.
Человек недоумевает, почему на одном компиляторе есть HF, а на
другом нет. - il-2(30.07.2023 11:09)
- Спасибо за развернутый ответ. "Ты ему разрешил". Так вот в этом и
вопрос, где в настройках компилятора это разрешается? Может я
недостаточно точно выразился: ИАР компилирует проект с файлами под
STM32F107 как КортексМ3 (не работает, ХардФалаут), а Кейл компилирует проект с файлами под STM32F107 как GD32F107(все
работает). Резонный вопрос, где в настройках то что отличает GD32F107 от стандартного Кортекса? - IBAH(30.07.2023 14:37)
- Совместимы только 103, в других даже адресация регистров иная. - Visitor(29.07.2023 13:56)
- Например, компилятор может неожиданно реагировать на Undefined
Behavior. Своими глазами видел, как компилятор применял чудесатую
оптимизацию адресной арифметики, потому что по каким-то
соображениям диапазон входных значений был ограничен. Когда в жизни
встречалось другое значение, арифметика вычисляла дикий адрес, и
вот тебе HardFault. А другой компилятор может этого не делать, и
твой косяк останется незамеченным. И да, это именно косяк в
исходнике. - SciFi(30.07.2023 14:55)