Ожидайте..

 
 
Новости
Документы
Прочее
Авторизоваться
 
крис касперски, ака мыщъх, a.k.a. nezumi, a.k.a. souriz, a.k.a. elraton, no-email

отладчиков уровня ядра под никсы — много, хороших из них мало (если такие вообще есть) и нужно быть нереально крутым хакером, чтобы с первого напаса выбрать такой дебагер, которым можно отлаживать, а не обламываться. перепробовав кучу отладчиков, мыщъх решил составить внятный обзор для начинающих, рассказывающий чем один отладчик отличается от другого и какой из них торкает, а какой никуда не канает кроме как в /dev/nul

введение

Существует множество интегрированных отладчиков для Linux'а, но ни один из них не включен в основную ветвь ядра, что выглядит странно, если не сказать подозрительно, особенно если учесть, что xBSD-системы включают в себя ядерный отладчик изначально (правда, во всех известных мне дистрибутивах он по умолчанию задисаблен и его активация требует перекомпиляции ядра).

Причина в том, что Линус Торвальдс (до сих пор стоящий у руля и принимающий решение о включении тех или иных компонентов в ядро) не доверяет интерактивным отладчикам и считает, что у "правильных" программистов таких потребностей просто не возникает. Типа, есть же отладочная печати (см . man printk) и ее, типа, вполне достаточно.

С Линусом, однако, согласны далеко не все разработчики и в определенных ситуациях без дебагера не обойтись, особенно если приходится отлаживать чужие модули, поставляемые без исходных текстов или ломать защиты, противостоящие отладчикам прикладного уровня. Так что, хочет того Торвальдс или нет, но "термоядерные" отладчики для Линуха все-таки есть, причем в количестве намного большим одного, причем, практически все они распространяется в исходных текстах и не требует денег. Казалось бы какая проблема — скачал, поставил, запустил….

Между тем, проблемы все-таки есть. Это и плохая совместимость неофициальных отладчиков в различными версиями официальных ядер и сложность выбора хорошего отладчика из кучи заброшенных проектов… Ситуация усугубляется тем, что различные отладчики предназначены для решения различных задач и потому на вопрос: "какой ядерный отладчик самый лучший" даются сильно неодинаковые ответы, зачастую без всяких пояснений! Ну и какая польза от таких советов?!

типы отладчиков

Классические ядерные отладчики (как для UNIX, так и для Windows) требуют наличия _двух_ компьютеров, на одном из которых устанавливается отлаживаемое ядро, а на другом — сам отладчик. Обмен данными обычно осуществляется по последовательному порту через нуль-модем, хотя можно встретить и другие варианты. Такие отладчики называются удаленными и к ним, в частности, относится знаменитый gdb (клиентская часть). Другая часть отладчика находится непосредственно в ядре и если там ее нет (а Linux'е ее нет), у нас ничего не получится. Очевидный недостаток удаленных отладчиков — необходимость приобретения второго компьютера, что далеко не всегда приемлемо (особенно для "домашних" хакеров). Виртуальные машины в какой-то мере снижают остроту проблемы, но…

Локальные отладчики выгодно отличаются тем, что позволяют отлаживать ядро на одной машине с отладчиком. Чаще всего они работают только в текстовом режиме. Поддержка консоли в графическом режиме (не говоря уже про X'ы) требует специальных "агентов", работающих далеко не везде и не всегда, а потому в ряде случаев приходится прибегать к удаленной отладке.

Конструктивно отладчики могут быть реализованы либо как неофициальный патч ядра (требующий его перекомпиляции), либо как драйвер, загружаемый в ядро налету зачастую даже без перезагрузки системы. Примером отладчиков первого типа служит KDB, второго — LinIce.

Однако, независимо от особенностей своей реализации, все Linux-отладчики страдают хронической проблемой совместимости с ядрами, поскольку, разработчики ядра не координируют свои действия с разработчиками отладчиков и потому последние поддерживают только фиксированный набор версий ядер, причем, поддержка новых версий как правило происходит с большим опозданием.

У xBSD таких проблем вообще по жизни нет, поскольку ядерный отладчик разрабатывается (и поставляется) вместе с сами ядром, и нормально поддерживает все графические режимы, в которых только работает сама xBSD.

использование отладочных возможностей VMWare

Начиная с версии 6.0 RC2 в популярной виртуальной машине VM Ware появился механизм Record/Replay, позволяющий (среди прочих возможностей) осуществлять удаленную ядерную отладку даже для тех операционных систем, которые поставляются без интегрированного отладчика: Linux, xBSD с выключенным отладчиком, NT, etc.

Просто добавляем в vmx-файл (описывающий конфигурацию виртуальной машины) строку "debugStub.listen.guest32=1" (или "debugStub.listen.guest64=1" для 64-разрядных платформ), после чего в vmware.log файле появляется следующая запись "VMware Workstation is listening for debug connection on port 8832", означающая, что виртуальная машина слушает 8832-порт с которым готова общаться по gdb-протоколу. Остается запустить сам gdb, приконнектится к порту и приступить к отладке безо всяких танцев с бубном, без наложения заплаток, без перекомпиляции ядра, etc.

Отладчик gdb может быть запущен как на хосте (основной операционной системе), так и на соседней виртуальной машине.

использование отладочных возможностей VM Ware 6.0 для отладки Linux'а без интегрированного отладчика

Для отладки нам потребуется _два_ комплекта ядер. Одно – установленное на отлаживаемой системе и другое – установленное на машине (реальной или виртуальной) где работает gdb. Отлаживаемое ядро может быть скомпрессированно и пострипано (как обычно и бывает), а вот ядро для gdb в обязательном порядке должно быть разжато (ну не понимает gdb сжатых ядер — что тут поделаешь!) и желательно откомпилировано с отладочной информацией. Как минимум, на машине с gdb должен присутствовать файл System.map. Естественно, версии обоих ядер должны совпадать, иначе начнется полный хаос.

Пара примеров работы с gdb представлена ниже:

# запускаем gdb
% gdb

# указываем путь к нескопрессированному 32-битному ядру
(gdb) file vmlinux-2.4.69-27.EL.debug

# коннектимся к отлаживаемому ядру
(gdb) target remote localhost:8832

# все! с этого момента можно начинать
# отладку ядра!!!

отладка x86-ядра Linux'а под VM Ware

# запускаем gdb
% gdb

# указываем путь к нескопрессированному 64-битному ядру
(gdb) file vmlinux-2.6.96-17.EL.debug

# переводим gdb в 64-разрядный режим
(gdb) set architecture i386:x86-64

# коннектимся к отлаживаемому ядру
(gdb) target remote localhost:8832

# все! с этого момента можно начинать
# отладку ядра!!!

отладка x86-64 ядра Linux'а под VM Ware

Естественно, ядро запущенное на эмуляторе, "видит" только виртуальное железо (исключение составляют USB-устройства, жесткие диски и сетевые карты) к которым VM Ware позволяет давать прямой доступ, однако, например, отладить драйвер видео-карты таким образом уже не получится.

Подробнее на эту тему можно почитать: http://stackframe.blogspot.com/ и http://blogs.vmware.com/sherrod/2007/04/index.html, а триальную версию VMWare скачать — http://www.vmware.com/download/ws

Полный текст