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

[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 и одну причину, почему мне это не подходит".
Хозяин - барин, конечно, но выглядит это всё довольно комично.

[jcxz]

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

Вообще-то вопрос был конкретный: про вставку пролога в функции в IAR. Ни одного дельного предложения по этому вопросу не было.
И причины я никакие не придумываю: причины все существуют, вот они передо мной, в проектах. Не понимаю - что именно комично? Объём кода большой (около 70 тыс. строк), памяти впритык (почти во всех проектах так), написателей кода - куча, задач - куча. И ПО ведёт себя как-то неадекватно. И что в этом случае делать-то прикажете? При каждой проблеме всё вручную пепрепроверять? Во всех режимах работы и функциях и их комбинациях коих тьма? И делать это после каждого внесения изменений в код каждым разработчиком? И что именно проверять? Как быстро определить где искать проблему???
Для такого тестирования у нас есть полигон, где стоит несколько десятков устройств и работают круглосуточно в реальных режимах работы. И нужно чтобы залить в них ПО и чтобы оно там крутилось долго и когда проявится проблема - вылетело на ловушку, сохранив состояние, по которому можно локализовать проблему.
Вот и хочется для наиболее типичных вариантов проблем (в частности - переполнение стека) сделать какие-то методы быстрой локализации, чтобы в случае поиска проблемы, быстро отсечь эти варианты.

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

[AlexandrY]

И причины я никакие не придумываю: причины все существуют, вот они передо мной, в проектах...

70 тыс. строк это несложный проект. В такой размер помещается простейшая RTOS и с пару десятков модулей с логикой и аппаратной поддержкой.
Такой проект должен делать один человек.
Переполнение стека это не типичная ошибка.
Косвенных вызовов в таком проекте будет не более десятка. У вас все решения лежат на виду.
Проблема чисто организационная. Либо у вас проблема с выбором платформы и отладочных инструментов.

Про "круглосуточно в реальных режимах работы" тоже можете не плакаться.
У нас в Австралийской пустыне и на Тайване техподдержка через teamwiewer собирает логи и апгрейдит программу.
В Саудовской Аравии специалист спокойно сидел на объекте и JTAG-ом ловил баги.
Китайцы, так те самостоятельно отреверсили наши протоколы, присобачили беспроводные модули и сделали круглосуточное наблюдение через облака.

Не далее как вчера мне пришла ссылка на хорошую статью про выбор платформы - http://www.edn.com/electronics-blogs/embed...ampaignId=29190

Сдается мне у вас скверно выбрана платформа ( ну кроме того, что еще и скверная команда)

[jcxz]

70 тыс. строк это несложный проект. В такой размер помещается простейшая RTOS и с пару десятков модулей с логикой и аппаратной поддержкой.
Такой проект должен делать один человек.
Переполнение стека это не типичная ошибка.
Косвенных вызовов в таком проекте будет не более десятка. У вас все решения лежат на виду.

Ну да-да - рассказывайте сколько у меня косвенных вызовов - Вам конечно виднее. И какая разница - сколько их? Что от этого меняется?
И про простейшую ОС - тоже. В каком-то ином мире Вы живёте видно. У нас ОС занимает менее 13тыс. строк. И это с кучей комментов и портом под ядро.
А в 70тыс.строк я ОС не включал. И эти 70тыс. - это почти без комментов.
И про объём это Вы похоже слабо владеете предметом. Вероятно у Вас ПО состоит из набора откуда-то стянутых чужих кусков. И для Вас писать ПО - слепить эти куски воедино. Так и 700тыс. - не проблема.
У нас же в этих 70тыс.строках нет ни строки чужого кода.

У нас в Австралийской пустыне и на Тайване техподдержка через teamwiewer собирает логи и апгрейдит программу.
В Саудовской Аравии специалист спокойно сидел на объекте и JTAG-ом ловил баги.

И что Вы этим хотели сказать??? У нас тоже основное ПО устройства обновляется удалённо через любой доступный канал связи по рабочему протоколу и без всяких тимвьюверов и безопасно. И даже с рестрансляцией через несколько устройств (если целевое устройство не поключено к глобальному каналу связи). И не только основное встроенное ПО можно обновить, но и встроенное ПО любого из входящих в состав устройства связных модулей (ZigBee, RF, GSM, PLC). И тоже безопасно.
Только какое это имеет отношение к вопросу???
Почему не получится отловить JTAG-ом, я тут уже несколько раз объяснил. Если не поняли - извините.

PS: Пустой трёп про китайцев в облаках поскипан.

[AlexandrY]

Только какое это имеет отношение к вопросу???

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

Ну разве это не диагноз?

[jcxz]

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

Я не обсуждаю здесь лошадей, не обсуждаю и проект. Это Вы всё время стараетесь стащить тему во флейм.
Вопрос был конкретный - в заголовке. Или более расширенно - о методах контроля стеков задач в многозадачной среде в общем случае, а не в частных типа: имеем вагон+тележка памяти и можем каждой задаче по мегабайту на стек выделить.
И чтобы это было удобно сделано - при малейшем подозрении на проблему со стеком: включил чекбокс/define, проконтролировал работу девайса в течение длительного времени на нескольких устройствах. И не надо было при каждом подозрении на стек, делать кучу ручной работы (ставить watchpoint-ы, снимать, просматривать стеки задач и т.п.). Я думаю это полезно будет не только в моих проектах.
Недостатки проектов, в которых я участвую, более здесь обсуждать я не намерен. Я их сам прекрасно знаю и чьё-либо мнение здесь на этот счёт меня не интересует.
Если нечем заняться и нечего сказать по существу - лучше пройдите мимо.