У меня есть драйвер I/O Kit: виртуальное сетевое устройство. После некоторого периода работы ОС зависает, так что похоже у меня какой-то тупик в драйвере.
Я проделал следующие шаги:
- подключил два макбука через FireWire
- поставил создать отладочную среду
- инициализировать NMI (через кнопку питания)
- подключиться к цели через gdb
- получить адрес моего kext
- создать и загрузить символы (это последнее точка во всех документах, которые я прочитал)
Пока все хорошо. В случае паники ядра этого будет достаточно. Но в моем случае паники ядра нет, и я нахожусь в потоке, который обрабатывает NMI.
Теперь вопрос: как мне переключиться на поток моего kext?
Команда showalltasks дает мне список всех задач, единственная задача, в которой может работать мой kext, это kernel_task, поэтому я пытаюсь изучить эту задачу через showtaskthreads и showtaskstacks, но не могу найти ничего похожего на мой код. Я что-то упустил?
Буду признателен за любые предложения или ссылки на документы.
Отладка kext с помощью gdb: тупик
Ответы (2)
Я не отвечаю на ваш вопрос напрямую, но можно ли поразить ваш kext-код точкой останова? Обычный метод отладки ядра состоит в том, чтобы запустить машину, подключить отладчик, установить точку останова в интересующем коде, возобновить выполнение (continue), а затем сделать все необходимое, чтобы достичь точки останова.
Ну, я отвечаю на свой вопрос.
Чтобы увидеть поток, использующий код моего kext, мне нужно переключиться на процесс, использующий мой kext. В моем случае это будет скорее всего браузер (поскольку мой кекст - NKE).
Но по факту мне это мало помогло. Но старый метод печати помог мне найти тупик. Поэтому мой совет следующий: при панике ядра - используйте отладчик, при тупиковой ситуации - используйте печать, найдите место блокировки и проанализируйте код.
