Исходное сообщение
"Дискуссия об использовании языка C++ для разработки ядра Lin..." Отправлено Аноним, 15-Янв-24 13:45
> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта > и они ничего не поймают, в продакшоне наконец-то в этот массив > запишут из сети 10 байт, запись затрет канарейки и структуры планировщика > FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и > девайс ребутнется по ватчдогу. Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно. ...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers. ...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта >> и они ничего не поймают, в продакшоне наконец-то в этот массив >> запишут из сети 10 байт, запись затрет канарейки и структуры планировщика >> FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и >> девайс ребутнется по ватчдогу. > Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и > получается. А я посмотрел на тойоту. Подумал. И теперь - даже > на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека > хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, > его нет), который не заметить очень сложно. Ибо самый суровый эксепшн > на все ядро, выбивающий все кроме NMI нафиг. И теперь мы > займемся реакцией на вот это, зная что в системе Ж, ждать > вачдог не обязательно. > ...а еще я таки сделал обработчикам приватный стек, так что они еще > и что-то сделать могут. Даже если основной стек кончился. У ARM > для этого довольно клевая фича есть, отдельный стек для handlers. > ...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case > рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем > фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое > время просим дамп оперативы, смотрим на регион стека, делаем выводы о > runtime margins.
	Введите код, изображенный на картинке: