Комментарии 25
А arm-*-*-gcc не поддерживается сознательно и принципиально?
Мы только начали адаптацию анализатора для ARM. Если Вы из этой сферы, то представляете, сколько нам ещё предстоит проделать работы по поддержке того или иного ARM-компилятора.
Почему не поддерживается, очень даже поддерживается, standalone-версия прекрасно перехватывает вызовы arm-gcc.
Хм, не совсем понял, причем тут перехват вызовов. Просто gcc не назван в числе поддерживаемых компиляторов, что я понял так, что анализатор может не поддерживать его особенности.
Для меня «не поддерживается» — это когда PVS вообще не понимает, что с этим компилятором делать. Насколько я понимаю, PVS-Studio анализирует не исходники напрямую, а уже препроцессированные файлы. И если компилятор не поддерживается, то сделать с этим вообще ничего нельзя было. Вот как с Кейлом и IAR'ом до сих пор было.
А arm-gcc поддерживается, я могу запустить компиляцию и PVS-Studio перехватит вызовы и проведет анализ; потому что формат препроцессированных файлов такой же, как у обычного gcc.
Вероятно, какие-то очень специфичные вещи при этом могут анализироваться неправильно, но я с таким не сталкивался.
А arm-gcc поддерживается, я могу запустить компиляцию и PVS-Studio перехватит вызовы и проведет анализ; потому что формат препроцессированных файлов такой же, как у обычного gcc.
Вероятно, какие-то очень специфичные вещи при этом могут анализироваться неправильно, но я с таким не сталкивался.
Понятно, спасибо! Но хотелось бы получить ответ от команды PVS.
Просто gcc не назван в числе поддерживаемых компиляторов
Что именно Вы имеете ввиду, GCC (Linux), MinGW, GNU Arm Embedded Toolchain?
А arm-*-*-gcc не поддерживается сознательно и принципиально?
Странный вопрос. В контексте Keil/IAR, очевидно, GNU Arm Embedded Toolchain. Если сможете сказать, поддерживается ли arm-linux*-eabi[hf] и другие компиляторы (имеются в виду arm-специфические нюансы) — тоже интересно.
Давайте так. Если у кого-то, что-то не работает, то просим писать в поддержку и мы постараемся оперативно помочь и выдать новую beta-версию при необходимости. Не хочется вести дискуссию на тему поддерживается/не поддерживается. Всё очень быстро будет меняться. И вот через пару месяцев кто-то почитает комментарии и расстроится, что нет поддержки gcc X. А она уже месяц как есть.
Т.е. поставщик коммерческого ПО не может сказать, в конкретной конфигурации будет работать или нет?!
Может. Но нет смысла делать это публично, поскольку это будет вводить в заблуждение. Мы не раз жалели, что где-то оставляли какую-то подобную информацию, а потом она вновь и вновь всплывает, хотя всё уже изменилось. :) Место такой информации у нас на сайте в разделе описания продукта и в ответах по почте клиентам и потенциальным пользователям.
Напишите пожалуйста в саппорт, что нам конкретно не работает, и мы постараемся решить проблему и поможем с проверкой проекта.
Напишите пожалуйста в саппорт, что нам конкретно не работает, и мы постараемся решить проблему и поможем с проверкой проекта.
Как заметил Amomum, анализатор уже запускается на arm-*-*-gcc, выдавая некоторые результаты. Работа ещё не закончаена, поэтому о поддержке не объвлено.
Было бы здорово аналогично проверить FreeRTOS.
В копилку зрелищных багов при программирование микроконтроллеров: geektimes.ru/post/295893
Насколько я знаю, в подобных системах есть функции типа sleep_us. Их и следует использовать для маленьких задержек. Компилятор вполне может превратить вызов функции sleep_us в обыкновенный простой цикл, но это уже особенности реализации. Руками же писать такие циклы задержки некрасиво и опасно.
Очень далеко не везде. Обычно производители контроллеров поставляют библиотеки, сфокусированные на упрощение работы с периферией контроллера, а формирование задержки больше алгоритмическая вещь. Чаще всего реализации этих sleep_us ищутся на форумах производителя.
Что же касается приведённого for-а — правила работы оптимизатора в мире эмбеддеда ничем не отличаются и при -O2 это цикл будет выкинут. Что бы это избежать, можно поставить _NOP. Ну или да, volatile на счётчик. Но и то и другое не годится в качестве реализации sleep_us, так как очень неточно (сильно зависит от оптимизации, требует отключения прерывания и тд). На армах я обычно использую реализацию на основе DWT счётчика.
А в целом спасибо. Я как раз прогнал проект, над которым работаю, через IAR-ровский анализатор, разочаровался в его качестве и начал задумываться, чем бы его ещё прогнать. Наверно теперь попробую PVS.
А для для компиляторов для PIC от Microchip не планируете? ;)
Пока не знаем. Зависит от того, будут ли подобные вопросы.
Небольшой оффтоп: а как вообще принимается решение о поддержке нового языка/ОС/компилятора? По обращениям потенциальных или текущих заказчиков, по инициативной разработке сотрудника, как-то еще? Почему-то кажется, что запросы на хабре или ситуации типа «у нас было 2 мешка травы...» имеют минорное значение.
здравствуйте. почему давно от вас ничего не слышно на ЛОРе?
Бан по причине, что там всем интереснее пьяные линуксоиды, а не обсуждение программистских тем. :)
Огорчает невозможность запуска на 32 разрядных версиях Windows.
Вышел обзор анализатора PVS-Studio с точки зрения разработки встраиваемых систем и поддержки стандарта MISRA C: PVS-Studio & KEIL 5 (STM32CubeMX) совместная работа.
Обзор нам понравился, и мы выражаем признательность автору. Спасибо ему за проделанную работу.
Аннотация автора:
Данное видео продолжает серию обзоров. В нём мы научимся использовать статический анализатор кода PVS-Studio совместно с интегрированной средой разработок KEIL 5 с применением генератора кода STM32CubeMX на практике и увидим, как нам это может упростить процесс разработки встраиваемых систем.
Несколько комментариев:
Иногда анализатор указывал на функции, в которых был виден только один оператор return. И было непонятно, почему PVS-Studio предупреждает о множественных return. Чтобы их найти, нужно заглянуть в макросы, используемые в функции. Какой-то из макросов содержит в себе оператор return.
Стандарт MISRA весьма педантичен и противоречив. На практике полностью удовлетворить ему невозможно. Например, невозможно не использовать union, если нужен этот самый union :). Диагностики MISRA делятся на 3 уровня: Required (требуемые/обязательные к правке), Advisory (рекомендуемые), Document (информационные предупреждения). Поэтому, когда говорят, что поддерживается MISRA, имеется в виду, что нет предупреждений типа Required (в PVS-Studio это предупреждения уровня High). Именно такую картину мы и видим в процессе проверки проекта. Нет ни одного предупреждения уровня High, т.е. нет предупреждений, обязательных к устранению. Так что действительно можно подтвердить, что проверенный проект советует стандарту MISRA C.
Данное видео продолжает серию обзоров. В нём мы научимся использовать статический анализатор кода PVS-Studio совместно с интегрированной средой разработок KEIL 5 с применением генератора кода STM32CubeMX на практике и увидим, как нам это может упростить процесс разработки встраиваемых систем.
Несколько комментариев:
Иногда анализатор указывал на функции, в которых был виден только один оператор return. И было непонятно, почему PVS-Studio предупреждает о множественных return. Чтобы их найти, нужно заглянуть в макросы, используемые в функции. Какой-то из макросов содержит в себе оператор return.
Стандарт MISRA весьма педантичен и противоречив. На практике полностью удовлетворить ему невозможно. Например, невозможно не использовать union, если нужен этот самый union :). Диагностики MISRA делятся на 3 уровня: Required (требуемые/обязательные к правке), Advisory (рекомендуемые), Document (информационные предупреждения). Поэтому, когда говорят, что поддерживается MISRA, имеется в виду, что нет предупреждений типа Required (в PVS-Studio это предупреждения уровня High). Именно такую картину мы и видим в процессе проверки проекта. Нет ни одного предупреждения уровня High, т.е. нет предупреждений, обязательных к устранению. Так что действительно можно подтвердить, что проверенный проект советует стандарту MISRA C.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статический анализатор кода PVS-Studio 6.22 адаптирован для ARM-компиляторов (Keil, IAR)