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

[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 тут тоже мало толку будет.
Таймлайн это все!