SVN r. 3909 добавил вывод дампа для содержимого стека от ESP+0, до ESP+32.
Бывает полезно, например, можно вычислить кто вызвал текущую процедуру, в которой произошла ошибка. Да, и вообще полезно знать не только адрес стека, а и его содержимое.
Я не уверен на все 100% в корректности работы - всегда возможны накладки, так что если у кого будут возражения/дополнения готов выслушать и внести изменения при необходимости.
Вывод отладочных сообщений (page fault и другие)
-
Last edited by Mario_r4 on Sat Sep 14, 2013 10:36 pm, edited 2 times in total.Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Безусловно полезно. Потестить еще не успел. Вопрос в том, как удобнее выводить - побайтно или поdwordно ?
UnКайF - это некоторое число такого же размера, как указатель. Что оно означает, знает только ядро. Драйвер может только передавать его ядру, когда хочет что-нибудь сделать. (c) CleverMouse
В стек заносится dword. Других размерностей не предусмотрено, потому и вывод сделал так же.UnКайF wrote:Вопрос в том, как удобнее выводить - побайтно или поdwordно ?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario_r4
Надо проверять esp на возможность доступа к памяти
код из page_fault_handler. ebx содержит проверяемый адрес
Надо проверять esp на возможность доступа к памяти
код из page_fault_handler. ebx содержит проверяемый адрес
Code: Select all
shr ebx, 12
mov ecx, ebx
shr ecx, 10
mov edx, [master_tab+ecx*4]
test edx, PG_MAP
jz .fail ;таблица страниц не создана
;неверный адрес в программе
mov eax, [page_tabs+ebx*4]
test eax, PG_MAP
jz .fail ;страница не присутствует
Спасибо за подсказку - добавил проверку в ревизии 3911.Serge wrote:Mario_r4
Надо проверять esp на возможность доступа к памяти
код из page_fault_handler. ebx содержит проверяемый адрес
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Сделал вывод символьных имён, если в корне образа присутствует файл kernel.dbg. О создании файла написано в теме про mtdbg. Сейчас он в сжатом виде занимает почти 40 кб.
Полезно или нет?
Полезно или нет?
Только сегодня делал себе.b00bl1k wrote:Сделал вывод символьных имён, если в корне образа присутствует файл kernel.dbg. О создании файла написано в теме про mtdbg. Сейчас он в сжатом виде занимает почти 40 кб.
Полезно или нет?
stacktrace.png
В стеке хранится адрес возврата из функции...+5 от точки вызова.
Адрес вызываемой и точку вызова надо вычислять.
Что за имя выводится?
Стектрейс бы сделать на уровне ОС....
Имя выводится, если значение из стека в пределах OS_BASE..endofcode. Само имя из файла kernel.dbg.
В ядре?Siemargl wrote:Только сегодня делал себе.
зачем мне ядро?b00bl1k wrote:Имя выводится, если значение из стека в пределах OS_BASE..endofcode. Само имя из файла kernel.dbg.
В ядре?Siemargl wrote:Только сегодня делал себе.
мне бы компилятор допилить...в либе
Переход на PE формат исполняемых файлов позволил бы хранить отладочную информацию.Siemargl wrote:Стектрейс бы сделать на уровне ОС....
рядом с файлом кладем .dbg файл и всёb00bl1k wrote:Переход на PE формат исполняемых файлов позволил бы хранить отладочную информацию.Siemargl wrote:Стектрейс бы сделать на уровне ОС....
переход на PE... но зачем ? win уже есть
аналогично с ELF
Причины уже озвучивались ранее. А в контексте этой темы - возможность сохранения отладочной информации в исполняемый файл самим компилятором без изобретения колёс и велосипедов.Siemargl wrote:но зачем?
только у каждого компилятора свой формат...b00bl1k wrote:Причины уже озвучивались ранее. А в контексте этой темы - возможность сохранения отладочной информации в исполняемый файл самим компилятором без изобретения колёс и велосипедов.Siemargl wrote:но зачем?
Возможно ошибаюсь, но стектрейс для уровня пользователя можно было бы сделать в kolibri.dll с помощью установки обработчика исключений.b00bl1k wrote:Переход на PE формат исполняемых файлов позволил бы хранить отладочную информацию.Siemargl wrote:Стектрейс бы сделать на уровне ОС....
Who is online
Users browsing this forum: No registered users and 1 guest