User Mode Stack в обработчике исключения, LPC2378 Exceptions Опции

[amw]

Для примера и определения архитектуры:
Процессор LPC2378, т.е. ARM7TDMI-S

Процессор работает в USER MODE. Происходит исключение, любое, UNDEF, PREFETCH ABTORT, DATA ABORT.
Переходим в обработчик.

Вопрос:
Как в обработчике исключения узнать значение регистра SP, из USER MODE?
Нужно положить на вершину USER MODE стека значение полученное в обработчике EXCEPTION.
В общем случае, нужно в обработчике исключения знать значене SP режима, в котором произошло это исключение.

Что-то в мануале на ARM найти не могу.
Может кто ткнет в правильный мануал или пример.

[zhevak]

Нужно положить на вершину USER MODE стека значение полученное в обработчике EXCEPTION.

Я извиняюсь. Правильно ли я понял, что USER MODE у Вас выполняется единственная функция?

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

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

Если Вам нужно из исключения передать какую-то инфу на уровень юзера, используйте глобальные переменные с модфикатором volatile. Зачем Вам проламываться через бурелом (там все равно ничего полезного нет! Одни траблы.), когда рядом лежит классическая ровная дорога?

[amw]

Я извиняюсь. Правильно ли я понял, что USER MODE у Вас выполняется единственная функция?

Нет.

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

Правильно. В исключении анализируется стеск на предмет вызова функций, переменных и т.д.

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

Если Вам нужно из исключения передать какую-то инфу на уровень юзера, используйте глобальные переменные с модфикатором volatile. Зачем Вам проламываться через бурелом (там все равно ничего полезного нет! Одни траблы.), когда рядом лежит классическая ровная дорога?

Это не то, что мне нужно.

Мне кажется, это иммитация вызова процедуры в USER MODE. Даже не иммитация, а принудительный вызов.

Почти, но не совсем.

ARM же не использует стек для возвратов. Да и вообще в ARM7 / ARM9 использование R13 как SP условно. (это в новых версиях архитектуры этот регистр жестко выделен под стек)

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

кстати zhevak задал хорошй вопрос.
зачем все это нужно?

Преследуются три цели.
1) - Вывод отладочной инфы (например в UART), дамп регистров, дамп стека и пр. Это скорее побочный эффект чем очень нужная функция в готовом устройстве.
2) - Реализация чего-то типа виртуальной памяти на архитектуре без MMU. В связи с отсутствием MMU DATA ABORT используется в соответствии с ARM Reference Manual для подгрузки данных. Еще один побочный эффект - PREFETCH ABORT используется для подгрузки кода. Итог - динамическая линковка.
3) - Наглядная демонстрация для студентов с целью научить их как это все работает. В общем тоже побочный эффект. Я в университете работаю.

Получается примерно так.

Код

@    Determine address of stack for mode where exception occurred
    mrs    r1, CPSR    @ Save current MODE
@    Switch in Prevoius Mode (where exception occurred)
    mrs    r2, SPSR
    mov    r3, r2
    bic    r3, r3, #0xFFFFFFE0
    cmp    r3, #USR_MODE
    moveq    r3, #SYS_MODE @ THUMB not supported
    bic    r2, r2, #0x1F
    orr    r2, r2, r3
    orr    r2, r2, #(I_BIT | F_BIT) @ THUMB not supported
    msr    CPSR, r2 @ THUMB not supported
@    Get sp and return to exception mode
    mov    r3, sp        @ Get sp
    msr    CPSR, r1    @ Restore Exception MODE

Вроде работает. Может кому пригодится.
Если до исключения мог быть THUMB режим - то нужно добавить дополнительный анализ и ветку кода с THUMB командами.
В данном случае меня это не интересует, потому и не заморачивался.
Критика принимается.

[KRS]

2) - Реализация чего-то типа виртуальной памяти на архитектуре без MMU. В связи с отсутствием MMU DATA ABORT используется в соответствии с ARM Reference Manual для подгрузки данных. Еще один побочный эффект - PREFETCH ABORT используется для подгрузки кода. Итог - динамическая линковка.

Вот это интересно! А как это можно реализовать?
(А то напоминает CPU not found! Press any key to software emulation... )

[amw]

Вот это интересно! А как это можно реализовать?
(А то напоминает CPU not found! Press any key to software emulation... )

Мысль о динамической линковке на ARM7 без MMU и ОС (имеется в виду что-то типа uClinux а не FreeRTOS и аналогичные) навеяна необходимостью "скрестить" в одном проекте библиотеки, распространяемые по разным лицензиям.
Например GPL + LGPL + BSD + что_то_еще_закрытое_и_проприетарное.

А сама линковка требует как минимум четырех компонентов.
1. Софт для преобразования библиотек в более подходящий для МК вормат. Например из ELF во что-то не такое громоздкое. Выполняется на ПК после линковки библиотеки. Выдает файл с таблицей соответствие символов, их адресов и места размещения. Адреса указываются принудительно так, что-бы вызвать DATA ABORT или PREFETCH ABORT.
2. Софт, выполняемый на ПК (пока хватает arm-elf-objcopy) для создания кусков прошивок. Прошивки содержат указанные выше таблицы. Ну и собственно код конечно .
3. Динамический линкер, исполняющийся на МК. Пока реализован (частично) как набор функций, вызываемых из обработчика исключения. Выполняет собственно поиск символов и закрузку кусков кода. Накладные расходы большие, так что использовать целесообразно для загрузки в память библиотеки целиком и редко.
4. Собственно программа МК, в том месте, где нужна библиотека, вызывает функции из таблиц. Таблицы содержат адреса, специально сформированные так, что-бы вызвать исключене. Кроме того, в связи с медлительностью процесса основная программа должна сначала вызвать функцию инициализации библиотеки, которая вызовет исключение, а дальше в работу вступает динамический линкер.

Слегка сумбурно, но процесс еще в самом начале.
Да, можно проще. И если бы не требования заказчика, я бы вообще не использовал закрытый софт. Но хозяи - барин, как говорится.