Как сделать полноценный SEH

Kernel architecture questions
  • Я совсем не против рефакторинга. Если код не используется лучше его удалить или явно закомментировать, а не прятать в макрос у которого совсем другая смысловая нагрузка. Для этого есть if 0 ... end if
  • Да без проблем.

    Кстати, if 0 заметить тоже не просто - я уже накалывался
    И думал, между прочим, что это все естественно и понятно
    Пример: programs\develop\libraries\libs-dev\.test\dll.inc
    Делаю я этот include, но у меня всего одна либа в проекте. Грубо говоря - dll.Load я не использую.
    Так она и не будет включена в мои коды.
    Написано не мной, ну я и считал это давно понятным и естественным :)

    Не знаю точно как в gcc, кажется там все, что написано в файле - будет тупо включено в коды...
    А вот в Дельфях, к примеру - ТОЛЬКО используемое. У них это правда называется smart-linkig, и жутко этим гордятся.
    Афигенный smart, конечно же... Доросли до возможностей встроенных макросов fasm-а :)
  • Кстати, if 0 заметить тоже не просто - я уже накалывался
    Поэтому чаще всего код просто комментируют
    ;
    ;
    ;
    ;
  • Serge wrote:Исключения POSIX подробно описаны в gnu libc manual
    http://www.gnu.org/software/libc/manual/pdf/libc.pdf - раздел 24 (Signal Handling)
    Правильно попал :?:
  • Ещё стоит посмотреть описание posix.1b posix.1c - стандарты для rtos.
  • Блин, ну очень не хотел... Но, видимо -- не отвертишься :D
    Ну ладно, закачал я это добро отсюда http://www.opengroup.org/onlinepubs/000 ... /susv3.zip
    Вот только понять не могу, чего из них 1b, а чего 1c
    там примерно такой выбор в менюхе слева
    Batch Services
    Development
    Headers
    Legacy Interfaces
    Math Interfaces
    Networking
    Realtime
    Threads


    И плюс такое - Select a volume: [ XBD | XCU | XSH | XRAT ]
    Что примерно расшифровывается как: [Base Definitions|Shell & Utilities|System Interfaces|Rationale]

    Serge, направьте на путь истинный... А то, с моим-то английским, это все год читать можно...
  • В общем, поизучал я немного систему сигнализации в posix и libc
    Дошел до перехода из ощущения, что "знаешь почти все" - в понимание, что процесс познания в данной области видимого конца не имеет.
    Пора принимать какое-то решение, и заканчивать дело конкретными кодами.

    Что я вижу в programs\develop\open watcom\trunk\clib\process\signl.c (имя файла - понравилось)
    Что из сигналов, порождаемых исключениями: SIGFPE, SIGILL, SIGSEGV - поддерживается только SIGFPE. Надо полагать, что к таковым же относятся SIGIOVFL и SIGIDIVZ, но таких определений я не нашел ни в стандарте libc, ни в posix.
    Вопрос - почему не поддерживатся. Ответ - потому-что таковых возможностей не предоставляет ось.
    Далее, про SIGFPE буквари рассказывают такое: The SIGFPE signal reports a fatal arithmetic error. Although the name is derived from “floating-point exception”, this signal actually covers all arithmetic errors, including division by zero and overflow
    Вопрос - почему сделано не так. Ответ - прежний.

    Далее, вопросы в порядке приоритетов

    1) Надо ли делать, чтобы ось такие вещи все-таки поддерживала? Если - "не очень-то и хотелось", то дальнейшее обсуждение бессмысленно. Поэтому исхожу в дальнейшем из - "надо, и обязательно"

    2) Надо ли сохранять при этом совместимось с нашими хуками исключений по FPU и SSE?
    Если сохранять, то все таковые сигналы мы должны обслужить адресами соответствующих обработчиков в APPDATA. Грубо говоря - на каждое исключение.
    И есть у меня ощущение, что это не очень рациональная трата ресурсов. Место в структуре закончится очень быстро.

    3) Если не сохранять, то надо выкинуть поля APPDATA.fpu_handler/sse_handler и заменить их на адрес единого для всех хэндлера и dword маски на все допустимые исключения проца. Интерфейс хэндлера при этом меняется - в стеке идет номер исключения, который надо снимать по выходе из хэндлера (зачем выходить - тоже интересный вопрос).
    Сопровождение. Гляжу в коды fpe387.asm::__Init_FPE_handler и fpeinth.asm::__FPE2Handler_ - вполне подъемная задача.
    Естественно, я оставлю старую функциональность - реагирование только на FPE
    Но, у С-developer-ов появится возможность реагировать (созданием соответствующих сигналов) на любые события из вышеперечисленных.
    Ну а KoOS - это просто пара десятков байтов кодов в sys32.inc, делов на вечер.

    =================================================================
    Крутилась у меня интересная мысль - полностью обратиться в веру сигналов/событий
    Долго крутилась...
    Т.е., к сигналам относятся как наши хуки исключений, так и ожидаемые нами события как "от драйвера", так и по f10/23.
    Грубо говоря - ничего в мире не существует кроме сигналов.
    Типа последние - это просто заблокированные сигналы, которые, в отличие от исключений, пользователь принимает чем-то похожим на sigwait. А исключения - это такие сигналы, которые блокировать глупо, мягко говоря.
    А вот иметь дополнительную возможность "захендлить" IRQ-сигналы - вовсе и не глупо...
    Да и "захэндленное" рисование - тоже можно обсуждать...

    Но я не готов еще к реализации такого глобального плана. Много вопросов, которые не очень понятно как решать пока.
    Но готов к обсуждению всех этих вопросов, коль скоро коллегам это будет интересно.
    Да и к реализации, коль скоро появится ясность
  • Про обратную совместимость с текущим обработчиком исключений ftp/sse думаю "не очень-то и надо".
    Если делать сигналы, то пусть все будет там, хоть и IRQ (может мы таки прийдем к микроядру?).
    В общем если есть желание, думаю стоит занятся, а люди готовые помочь / пообсуждать думаю есть, как и интерес.
  • /может перейдем на AMD64 ? т.к. сейчас выпускают процессоры с поддержкой AMD64/EMT64./
    PS мои познания в особенностях этих режимов скудны.
  • А давайте и на асм забъем? Все равно ведь ядро уже почти одни сплошные макросы... ну, его к черту этот муторный ассемблер. Вот понимаешь все пишут на Си, все пишут используя L4, и ваапще зачем оно ведь уже есть Линупс в котором есть все, даже то что нужно. А может вообще сразу на Яве ваять? И вообще просить у Гугла исходники Андройда? Ну, епть ну зачем нам это гребанй асм? А?!
  • Не млин, давай те лучше оставим сталые костыли, и ещё придумаем новые???
  • О чем это ВЫ: /может перейдем на AMD64 ? т.к. сейчас выпускают процессоры с поддержкой AMD64/EMT64./
    Мои познания в этих технологиях еще более скудны. Поэтому не понял как связи с "обработкой исключений", так и смысла последовавших ответов.

    Расшифруйте, пожалуйста.
  • <Lrz> "— Обязательно бахнем! И не раз — весь мир в труху!.. Но потом."... ДМБ
    Galkov не обращай внимания
  • Вот чего я думаю.
    Для большинства прикладных программистов, все это словеса умные и непонятные....
    Наверное.

    Может где-то как-то выложить простенький пример.
    Типа 2 основых ф-ии:

    Code: Select all

    int __TRY(void func(void*), void*lParam);
    void __RISE(int Ecx, void*ExcData);
    Хотя бы простейший однопроходный вариант, объемом так строк на 20 asm-а

    Простенькая вещь в стиле Forth: __TRY запускает func в режиме перехвата исключений
    Если вернулся 0 - все было тип-топ. Иначе - номер исключения. Если это "не твое" -- делай __RISE, и не напрягайся. Получится вложенная сруктура.
  • Who is online

    Users browsing this forum: No registered users and 8 guests