В нашей повседневной работе, как и всем, требуется много пользоваться отладчиком. В силу специфики работы: (разработка ОС, использование технологий виртуализации наподобие Intel-VT, ит.д.) нам часто требуется использовать отладчик для работы со специфическими случаями: отладка кода загрузчика ядра, отладка загрузчиков виртуальных машин, а так же в принципе обеспечение возможности отлаживать ОС собственной разработки. Именно эти особые случаи так пафосно названы в заголовке ”по максимуму”.
Для решения всех этих задач (и конечно, многих других) мы используем gdb. Возможно использование и таких оболочек как DDD, но лично я предпочитаю использовать cgdb как оптимальный выбор, особенно для случая работы с отладчиком по ssh.
В этой статье мы расскажем о том, как можно использовать gdb для отладки кода загрузочных секторов и загрузчиков.
В начале разработки любой новой ОС, требуется обеспечить и наличие банального загрузчика для этой ОС. «Правда жизни» разработчика ОС заключается в первую очередь в том, что процессор начинает выполнять код загрузочного сектора срезу после BIOS Post в Real Mode. На этот момент никакой ОС еще не загружено (только 512 байт загрузочного сектора), в то время как для полноценной поддержки отладчика нам требуется реализация особого модуля в ядре ОС (об этом подробнее в части 2). Возникает вопрос: как же отлаживать код бут-сектора и загрузчика? Ведь до начала работы с основным отладчиком ОС (через специальный модуль) необходимо провести загрузку в оперативную память “загрузчика системы”, загрузку ядра и его базовых модулей, базовую инициализацию аппаратуры (для работы с gdb нужен по крайней мере Serial Port), и только потом работа с полноценным отладчиком ОС становится возможной.
Решить эту проблему можно, как оказывается, довольно просто: нужно начать загрузку ОС внутри какой-нибудь виртуальной машины, которая поддерживает встроенные функции отладки.
В качестве примера приведем описание использования qemu:
1. Запускаем виртуальную машину (для примера используется простая загрузка ОС с дискеты):
qemu -fda ./boot.fdd -s -S -vnc none &
(Запускаем qemu виртуальную машину, которая будет загружаться с дискеты, образ которой находится в файле “./boot.fdd”; “-s –S” означает, что машина запустится в приостановленном режиме и в режиме отладки; “-vnc none” означает, что машина запустится без активного терминала (то есть, в фоновом режиме – особенно удобно при работе через ssh, да и для отладки загрузчика и бут сектора видеть экран компьютера редко требуется); “&” — запускаем виртуалку в фоновом режиме).
2. Теперь, запускаем сам отладчик gdb:
$ gdb
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<www.gnu.org/software/gdb/bugs/>.
(gdb)
3. В отладчике gdb коннектимся к порту qemu:
(Gdb) target remote localhost:1234
Кстати этот порт виден в netstat:
$ netstat –tlpn
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN 4014/qemu
Обратите внимание на адрес, с которого мы начинаем отладку:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000fff0 in ?? ()
(gdb)
С этого адреса начинает свою работу любой процессор при включении питания. Другими словами мы оказались прямо в начале работы BIOS (внутри виртуальной машины, естественно).
4. Далее нам надо подготовить gdb к отладке Real Mode кода:
(gdb) set arch i8086
The target architecture is assumed to be i8086
(gdb)
5. Теперь нам нужно поставить первый брэйкпоинт на начало нашего загрузочного сектора:
(gdb) break *0x7c00
Breakpoint 1 at 0x7c00
(gdb)
(BIOS загрузит первые 512 байт с указанного устройства (с дискеты) в память по адресу 0x7c00 и передаст управление на эту область памяти).
6. Прыгаем в наш загрузочный сектор:
(gdb) c
Continuing.
Breakpoint 1, 0x00007c00 in ?? ()
(gdb)
7. Готово! Можно отлаживать наш код!
Существует ряд особенностей отладки кода отладчика, с которыми приходится работать.
Во-первых, нужно учитывать особенности адресации данных в режиме RealMode. Любая информация адресуется как segment:offset, при этом адрес можно посчитать как: segment * 16 + offset. Это означает, что для того, чтобы прочитать первые 10 инструкций кода, начиная с текущей инструкции, нужно использовать команду: (gdb) x/10i $cs*16+$eip. Неудобство в данном случае заключается в том, что текущую инструкцию gdb показывает без учета базы сегмента кода:
(gdb) x/10i $cs*16+$eip
0x80000: jmp 0x90013
0x80002: (bad)
0x80003: mov $0x8,%di
0x80006: add $0xff,%al
0x80008: aas
0x80009: add %al,(%bx,%si)
0x8000b: add %al,(%bx,%si)
0x8000d: add %al,(%bx,%si)
0x8000f: add %al,(%bx,%si)
0x80011: add %al,(%bx,%si)
(gdb)
В то время как адрес инструкции равен:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb)
Во-вторых, приходится вручную устанавливать и снимать брэйкпоинты. Это означает, что если вы поставили брэйкпоинт на адрес:
(gdb) break *0x80017
Breakpoint 4 at 0x80017
…затем попали на него..:
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000017 in ?? ()
(gdb)
…а потом сделаете stepi, то вы опять попадете на брэйкпоинт, вместо выполнения самой инструкции и перехода на следующую:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000017 in ?? ()
(gdb) stepi
0x00000017 in ?? ()
(gdb)
Поэтому, процесс отладки может выглядеть примерно следующим образом:
1. где-то в коде загрузчика:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000023 in ?? ()
(gdb) x/10i $cs*16+$eip
0x80023: mov %ebx,0xb
0x80028: movl $0x0,0xf
0x80031: call 0x80c15
0x80034: or %ax,%ax
0x80036: je 0x80087
0x80038: call 0x809af
0x8003b: call 0x80193
0x8003e: or %ax,%ax
0x80040: je 0x80268
0x80042: mov $0x3f4,%dx
(gdb)
2. ставим брэйкпоинт, срезу после call:
(gdb) break *0x8003e
Breakpoint 6 at 0x8003e
3. запускаем программу до этого брэйкпоинта:
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000003e in ?? ()
(gdb)
4. удаляем брэйкпоинт:
(gdb) delete 6
(gdb)
5. проверяем возвращаемое значение:
(gdb) print /x $ax
$2 = 0x8000
(gdb)
6. делаем шаг далее:
(gdb) stepi
0x00000040 in ?? ()
(gdb)
А вот так можно прочитать значение одного из параметров функции:
(gdb) x/1w $ss*16+0x12
0x70012: 0x00b8fa00
(gdb)
Мы часто пользуемся этим методом. Правда, приходится его использовать совместно с еще парочкой других (например, отладка виртуальной машины в виртуальной машине), что немного усложняет работу, но суть остается прежней.
Автор: NWOcs
