Обязательный префикс функции. Опции

[jcxz]

Интересно - есть-ли у IAR возможность вставки префикса в начало каждой функции при компиляции?
Т.е. - чтобы после входа в каждую функцию в проекте, после PUSH, он вставлял некий фиксированный код (hook). Возможно это несколько ассемблерных строк или просто вызов функции BL (естественно с предварительным сохранением исходного LR на стеке). Видел такую возможность у какого-то компилятора, не помню точно, но вроде у CCS.
Думаю добавить в проект функционал контроля стеков задач. И думаю как это удобнее всего сделать. С помощью такого хука это можно было-бы реализовать.

[scifi]

Вроде бы всю жизнь это называлось "пролог".

[jcxz]

Вроде бы всю жизнь это называлось "пролог".

По этому слову в доке IAR тоже ничего не находится....

[AlexandrY]

По этому слову в доке IAR тоже ничего не находится....

Специально залез в доку IAR посмотреть наличие проблемы, потому как немыслимо чтобы IAR не выделял внимания контролю стека.
Ну и точно, там море возможностей прецизионно контролировать стек.
Читайте EWARM_DevelopmentGuide.ENU.pdf со страницы 92

Не поверите, но sprintf() не использую нигде в embedded (в IAR и CCS по-крайней мере). В IAR-проектах вместо неё использую _Printf() - она удобнее.

Почему же, верю.
В моих проектах можно найти по 3-4 отдельных автономных реализаций sprintf.
Ибо каждая RTOS, каждый пакет претендующий на мультиплатформенность содержит файлы с переписанными стандартными библиотеками C-и.
Это не удобство, а трагедия, поскольку возникает еще один повод для путаницы.

[jcxz]

Специально залез в доку IAR посмотреть наличие проблемы, потому как немыслимо чтобы IAR не выделял внимания контролю стека.
Ну и точно, там море возможностей прецизионно контролировать стек.
Читайте EWARM_DevelopmentGuide.ENU.pdf со страницы 92

Именно эту доку я и изучал. На этой странице у меня "CHOOSING A LINKER CONFIGURATION FILE" и др. мало относящиеся к контролю стека главы.
Не сочтите за труд указать название главы?

Ибо каждая RTOS, каждый пакет претендующий на мультиплатформенность содержит файлы с переписанными стандартными библиотеками C-и.
Это не удобство, а трагедия, поскольку возникает еще один повод для путаницы.

Я не гонюсь за мультиплатформенностью. Она малополезна в embedded, когда проект привязан даже не только к ядру, но и более сильно - периферии.

[AlexandrY]

Не сочтите за труд указать название главы?

Я не гонюсь за мультиплатформенностью. Она малополезна в embedded, когда проект привязан даже не только к ядру, но и более сильно - периферии.

"Stack usage analysis"

А кто гонится? Все мы работаем одинаково.
Поэтому я и знаю где реальная проблема обсуждается, а где надуманная или несущественная.

Открытые проекты с исходниками все поголовно мультиплатформенные, это не нам решать, это их природа такая, иначе они не выживают.
Мы их берем и затачиваем.
А если не можем заточить, то юзаем GCC и говорим что это круто.

[jcxz]

"Stack usage analysis"

Не подходит. Толку от него мало. В коде куча косвенных вызовов функций.
И это не подходит: but if there are indirect calls (calls using function pointers) in your application, you must supply a list of possible functions that can be called from each calling function.
Так как не я один пишу этот код, а есть товарищи, любящие всякие классы с виртуальными член-функциями и пихающие их куда нужно и не нужно. А заставить их делать это для своего кода - нереально. Да и малоэффективно.
Да и опять-же - в случае использования чужого кода (всяких стеков и либ), что делать? Шерстить весь этот код для supply a list of possible functions???
Нужен именно run-time контроль, а не build-time.

[AlexandrY]

Не подходит. Толку от него мало. В коде куча косвенных вызовов функций.

Так как не я один пишу этот код, а есть товарищи, любящие всякие классы с виртуальными член-функциями и пихающие их куда нужно и не нужно. А заставить их делать это для своего кода - нереально. Да и малоэффективно.

Не куча, а где нибудь в районе сотни.
IAR все косвенные вызовы аккуратно показывает в Call graph-е.

Если у вас есть к тому же товарищи, то раздать им по десятку таких вызовов и вы за день сделаете управляющий файл для анализатора вызовов.
По любому косвенные вызовы надо знать в лицо, как самые граблеопасные места.

Про эффективность не понял. Анализатор вызовов абсолютно точно считает стек.
И если стоит задача урезать максимально стек лучшего способа не существует.

[jcxz]

Если у вас есть к тому же товарищи, то раздать им по десятку таких вызовов и вы за день сделаете управляющий файл для анализатора вызовов.
По любому косвенные вызовы надо знать в лицо, как самые граблеопасные места.

Это Вы так считаете. И я. А товарищам объяснить невозможно - они всё равно делают как делали и не хотят ни в чём разбираться. А ПО потом глючить начинает совсем в другом месте, не там где набыдлокодили.

Про эффективность не понял.

Неэффективно, так как требует постоянного контроля кода, заполнения чего-то там при каждом изменении/добавлении/убирании этих самых функций. Да и ещё и правильного заполнения. 100% что забудут добавить или неправильно добавят или.... и всё насмарку - опять ищи почему глючит.
Механизм контроля должен быть внешний, не требующий постояных трудозатрат на его поддержание и чтобы его один раз реализовал и забыл. И только включать быстро (одним дефайном или ещё чем) когда надо и отключать когда не надо.
А иначе проще тогда уж по-старинке: залить стеки шаблоном и глазами проконтролировать затёртость шаблона.

[AlexandrY]

Неэффективно, так как требует постоянного контроля кода, заполнения чего-то там ...

Т.е. хотите забабахать статистический движок как в линуксах?
И стека не жалко, и ресурсов процессорного времени и риалтайма?

Я думаю если даже Segger этого не сделал, то это никому и не надо.
Старых добрых методов хватает.

Да и статистика дело тонкое.
Не скажете же заказчику после того как все рухнуло, что вероятность переполнения стека была всего то 0.1% с уровнем доверия 95% при эмпирической гипотезе о распределении.

[jcxz]

Т.е. хотите забабахать статистический движок как в линуксах?
И стека не жалко, и ресурсов процессорного времени и риалтайма?

Причём тут какой-то движок? Причём тут заказчик??? Речь идёт об отладке ПО и средствах отладки.
Идея простейшая: при каждом изменении SP (в си - после входа в функцию и выделения стекового фрейма), проверять SP на допустимость (нахождение в некотором диапазоне адресов). Переменные, хранящие контролируемый диапазон, обновлять при каждом переключении задач (в соответствующем хуке ОС).
Это если бы была возможность написать свой пролог функции.
Если нет, другой способ: так же контролировать SP на нахождение в диапазоне только периодически, как можно чаще, в высокочастотном таймерном прерывании.

Дополнительного стека для этого не нужно. Процессорное время конечно нужно, но этот контроль нужно включать только тогда когда нужно - при отладке, при возникновении подозрения на переполнение стека, при каком-то непонятном поведении ПО, чтобы отбросить вариант переполнения стека.
Когда проверять не нужно - просто комментируем соответствующий #define и всё. У меня сейчас так же уже реализована проверка на максимальную длительность запрета прерываний в ПО: запускается ВЧ прерывание и контролируются интервалы времени между прерываниями. Работает отлично - уже не одно место нашёл, где коллеги кривыми ручками надолго запрещали прерывания, нарушая тем самым работу драйверов периферии.
Можно конечно по-старинке: просматривать затёртость шаблона заполнения стека. Но это менее удобно и самое главное - высока вероятность пропуска некоторых случаев переполнения стека.

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

[scifi]

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

Ну здрассте. Есть же watchpoint, он же data breakpoint.

[jcxz]

Ну здрассте. Есть же watchpoint, он же data breakpoint.

А каким образом с его помощью можно контролировать SP или доступ к памяти через SP?
Оно вроде насколько я знаю только контролирует доступ к памяти вне зависимости от регистра из которого была запись/чтение. Или у меня J-Link какой-то урезанный???

[AlexandrY]

А каким образом с его помощью можно контролировать SP или доступ к памяти через SP?

Да никак, никому это не нужно.

Сначала скажите, вы боретесь с ошибкой или с саботажем?
Если с ошибкой, то ставите watchpoint на проблемном месте и находите баг за считанные минуты. Тут даже говорит не о чем.
Подбирать нужную глубину стека новички учатся на первый год стажировки.

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

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

Скажем засекаем метки времени в своем прерывании и делаем останов когда время затянулось дольше обычного.
Правда без таймлайна JLink тут тоже мало толку будет.
Таймлайн это все!

[jcxz]

Да никак, никому это не нужно.
Сначала скажите, вы боретесь с ошибкой или с саботажем?
Если с ошибкой, то ставите watchpoint на проблемном месте и находите баг за считанные минуты. Тут даже говорит не о чем.

Я вижу саботаж только здесь.
Вы действительно не понимаете сути вопроса или это троллинг?
Мне кажется вопрос кристалльно ясен. Ситуация:
void f()
{
char b[100];
b[0] = некое_выражение;
...
}
Эта функция вызывается когда до границы стека текущей задачи осталось например 50 байт.
Внимание вопросы:
Что будет со стеком и с SP?
Что будет с памятью, находящейся ниже стека текущей задачи?
Каким образом при помощи watchpoint (или каких-то других сервисов) обнаружить факт выхода SP за границы стека текущей задачи (и записи по SP) в такой ситуации?
При условии что в памяти расположенной ниже стека текущей задачи, могут находиться другие переменные, запись в которые через другие регистры (не SP) - штатна, и запись через SP из других задач - штатна, и не должна вызывать срабатывания механизма обнаружения переполнения стека.
В качестве доп. условий: работа идёт в многозадачной среде, есть N задач, каждая со своим стеком.

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

Если частота его будет такова, что прерывания будут происходить каждые десяток-два команд, то высока вероятность того, что SP уже сбился и выполнение начало куда-то уходить, но содержимое регистров/памяти ещё не успело разрушиться настолько что невозможно найти место где произошло выполнение или CPU вообще не завис.
Т.е. - функция то исправна, и она продолжает выполняться, ну разрушила она чужую память, находящуюся ниже её стека, ну были там адреса возврата, по которым PC улетит в неизвестном направлении, но это случится только когда ОС передаст управление той задаче, чьи данные были разрушены. Это может быть не скоро и до этого успеет сработать ловушка по ВЧ прерыванию, контролирующая SP.

Вот был у нас такой реальный факт переполнения стека:
Проблемный стек, переполнялся только иногда, когда по протоколу обмена устройству приходили только определённые запросы от клиента в заранее непредсказуемое время, которые обрабатывались задачей обработки протокола обмена сессионного уровня. Ниже проблемного стека находилась область памяти связных блоков данных (построенная типа массива блоков фиксированного размера, выделяемых динамически по запросу драйверов каналов связи). В эти блоки драйвера каналов связи писали входящие кадры протокола обмена (и исходящие тоже).
Устройство может работать по нескольким каналам связи одновременно, все драйвера каналов связи асинхронны друг к другу.
Симпотмы проявления: иногда почему-то устройство не отвечало на запросы клиента, причём совершенно произвольно - то всё ок, то какие-то запросы почему-то терялись. Хотя канал связи - идеальный, помех не должно быть.
И вот как тут можно было решить, что переполняется стек одной из задач? И как обнаружить проблемное место куда надо вставить этот диагностический код?

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

Это Вы про то что я писал про контроль длительности запретов прерываний? Ну так у меня это примерно так и работает, только не надо ставить такие метки в каждое прерывание, убирать их и пр. гемор. Просто разрешается некий #define, начинает работать ВЧ прерывание, выполняющееся на высшем приоритете, и оно измеряет временные интервалы между своими вызовами и если есть преывешние - ахтунг! - попадаем в ловушку.
В любой момент когда возникло подозрение можно этто define включить и проверить. Это просто. Хочется чтобы и контроль стека включался так же просто.

[AlexandrY]

Мне кажется вопрос кристалльно ясен. Ситуация:
void f()
{
char b[100];
b[0] = некое_выражение;
...
}

Ситуация совершенно не реалистичная.
Разработчик под RTOS никогда так не сделает. И вы наверняка так не делаете, ибо эти грабли быстро все понимают.
Здесь либо используется динамическое выделение, либо массив делается глобальным, либо разработчик сразу же тестирует этот код на переполнение стека.

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

И вот как тут можно было решить, что переполняется стек одной из задач? И как обнаружить проблемное место куда надо вставить этот диагностический код?

А это делается в несколько ходов.
Сначала вставляется лог приема-передачи пакетов.
Потом по логу обнаруживается несоответствие поведения.
Находится машина состояний ответственная за соответствующее поведение.
Потом вставляются в ветви состояний команды типа ITM_EVENT(можно даже с аргументом в виде значение стека) и вставляется код с остановом с идентификацией аномального поведения.
И в таймлайне после останова уже смотрят какие прерываний были, сколько длились и какие состояния автомата предшествовали.
Если как в вашем случае обнаруживаем искаженные данные, то ставим на них watchpoint. И все!
На следующем прогоне видим кто (какая задача, процедура, функция ..) портит данные.

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

У меня ошибок стека уж не помню сколько лет не было.

[jcxz]

Ситуация совершенно не реалистичная.
Разработчик под RTOS никогда так не сделает. И вы наверняка так не делаете, ибо эти грабли быстро все понимают.

Не понимаю... В чём её нереалистичность??? Под RTOS нельзя объявлять массивы на стеке?

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

Попробуйте иногда заглядывать в результирующий асм-код после компилятора.
При выделении стекового фрейма на входе функцию, компилятор удаляет этот фрейм только при выходе из функции. По-крайней мере и IAR и CCS так генерят.
И такой супервизор может пропустить это только если выход случится быстро после входа, что маловероятно (хотя вполне возможно - такой способ не даёт 100%-гарантии обнаружения).

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

Очень сложно и громоздко.
Представьте что этот сбой происходил не каждый раз при тестировании, а только иногда редко, выявлялся установкой на прогон нескольких устройств и их кргулосуточной работой.
Просто он проявлялся при попадании определённых запросов от клиента в определённые времена работы ПО, что происходило редко и недетерминированно по времени.
Это придётся кучу логов перелопатить и watchpoint-ы не помогут - много устройств - неужто на каждый комп с JTAG-ом ставить?

Соглашусь. Проектировать задачи так, что на стеке выделяются здоровенные куски памяти это системная ошибка .

char b[100] - это только для примера. Если там будет char b[10] - легче что-ли?
Или например - просто вызов sprintf()

Разве не очевидно?
Настраивать watchpoint на область памяти некоторого разумного размера за стеком, куда полезут данные при переполнении. Настраивать в переключалке задач, чтобы контролировать актуальный стек. Стеки разместить с нужным выравниванием, чтобы всё это было возможным.

Какой для этого J-Link нужен? Мой J-Link не умеет "Настраивать watchpoint на область памяти", а только на конкретный адрес. Ну можно конечно выровнять стек на границу степени 2 и настроить на адреса ниже воспользовавшись маской адреса. Но это тогда куча ОЗУ на это понадобится дополнительного.
А её просто нет. У нас проект уже большой, там ОЗУ не хватит уже даже на массив из нескольких десятков байт, не то что выровнять все стеки всех задач (их около 10) да ещё выделить ниже каждого по приличному куску памяти.
Если-б у меня было столько памяти, я бы просто задействовал MPU: при входе в задачу стек в отдельный регион с разрешением для него, для BSS - другой регион с защитой и т.п. И все регионы на расстоянии друг от друга. Я об этом писал ещё в самом начале топика.
И во-2-ых - события переполнения могут происходить редко и приходится ставить несколько устройств на длительный прогон. И нет возможности сидеть над каждым устройством с JTAG-ом.

[scifi]

И нет возможности сидеть над каждым устройством с JTAG-ом.

О господи. Эти самые watchpoint можно настраивать через регистры без всяких жтагов.

[jcxz]

О господи. Эти самые watchpoint можно настраивать через регистры без всяких жтагов.

Хорошо. Но как быть с ОЗУ?

Не сочиняйте.
При 10 задачах у вас должно быть море лишней памяти если вы не делали статический анализ стека.

Не вижу моря. Вам видно виднее сколько памяти в моём проекте.

[scifi]

Хорошо. Но как быть с ОЗУ?

Это ваши проблемы.
Пока я вижу такой настрой: "Вы тут мне предлагайте всякое разное, а я придумаю 1000 и одну причину, почему мне это не подходит".
Хозяин - барин, конечно, но выглядит это всё довольно комично.