Use correct syntax markup for shell
Approved by: carlavilla
This commit is contained in:
Li-Wen Hsu
parent
55c95407aa
commit
a9a9e66105
666 changed files with 17924 additions and 17924 deletions
|
|
@ -55,7 +55,7 @@ authors:
|
|||
====
|
||||
Удостоверьтесь, что каталог `dumpdir`, указанный в man:rc.conf[5], существует до аварийного останова ядра!
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# mkdir /var/crash
|
||||
# chmod 700 /var/crash
|
||||
|
|
@ -76,7 +76,7 @@ authors:
|
|||
|
||||
Если вы тестируете новое ядро, но вам нужно загрузить и работать с другим ядром, чтобы получить нормально функционирующую систему, то загрузите его в однопользовательском режиме при помощи флага `-s`, указываемого при загрузке, а затем выполните такие шаги:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# fsck -p
|
||||
# mount -a -t ufs
|
||||
|
|
@ -102,7 +102,7 @@ authors:
|
|||
|
||||
Чтобы войти в отладчик и начать получать информацию из дампа, как минимум необходимо сделать следующие шаги:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# cd /usr/obj/usr/src/sys/KERNCONF
|
||||
# kgdb kernel.debug /var/crash/vmcore.0
|
||||
|
|
@ -112,7 +112,7 @@ authors:
|
|||
|
||||
Этот первый дамп взят из ядра 5.2-BETA, а сбой произошёл где-то глубоко внутри ядра. Нижеследующая выдача была модифицирована, в неё слева добавлены номера строк. При первой трассировке проверяется указатель команд и выдаётся обратная трассировка. Адрес, используемый в строке 41 для команды `list`, является указателем команд и он может быть найден в строке 17. Большинство разработчиков будут требовать предоставления им по крайней мере этой информации, если вы не можете отследить проблему самостоятельно. Если, однако, вы решите проблему, то обязательно добейтесь включения вашего патча в дерево исходных текстов, прислав его через сообщение об ошибке, списки рассылки или даже его непосредственным коммитом!
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
1:# cd /usr/obj/usr/src/sys/KERNCONF
|
||||
2:# kgdb kernel.debug /var/crash/vmcore.0
|
||||
|
|
@ -208,7 +208,7 @@ authors:
|
|||
|
||||
Во второй трассировке используется более старый дамп из времён FreeBSD 2, но он более сложный и показывает больше возможностей `gdb`. Длинные строки были усечены ради повышения читабельности, а также пронумерованы для того, чтобы ссылаться на них. Кроме этих отличий, это реальная трассировка ошибки, выполненная в процессе разработки консольного драйвера pcvt.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:# cd /sys/compile/URIAH
|
||||
|
|
@ -317,7 +317,7 @@ authors:
|
|||
|
||||
Возможно также и исследование аварийного дампа ядра при помощи такого графического отладчика, как `ddd` (вам потребуется установить порт [.filename]#devel/ddd#, чтобы использовать отладчик `ddd`). Добавьте флаг `-k` к командной строке `ddd`, которую вы обычно используете для его вызова. Например;
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ddd -k /var/crash/kernel.0 /var/crash/vmcore.0
|
||||
....
|
||||
|
|
@ -369,7 +369,7 @@ options DDB
|
|||
|
||||
Вторым способом является переход в режим отладчика сразу после загрузки системы. Есть два простых способа этого добиться. Если вы хотите перейти в отладчик из командной строки, просто наберите команду:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# sysctl debug.enter_debugger=ddb
|
||||
....
|
||||
|
|
@ -380,7 +380,7 @@ options DDB
|
|||
|
||||
Команды DDB примерно повторяют некоторые команды `gdb`. Первым делом вам, наверное, нужно задать точку останова:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
b function-name
|
||||
b address
|
||||
|
|
@ -390,14 +390,14 @@ options DDB
|
|||
|
||||
Чтобы продолжить работу прерванного ядра, просто наберите:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
c
|
||||
....
|
||||
|
||||
Чтобы получить трассировку стека, задайте:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
trace
|
||||
....
|
||||
|
|
@ -409,7 +409,7 @@ options DDB
|
|||
|
||||
Если вы хотите убрать точку останова, введите
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
del
|
||||
del address-expression
|
||||
|
|
@ -417,21 +417,21 @@ options DDB
|
|||
|
||||
В первом варианте команда будет исполнена сразу же по достижении точки останова, а текущая точка останова будет удалена. Во второй форме можно удалить любую точку останова, однако вам нужно будет указать ее точный адрес; его можно получить из:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
show b
|
||||
....
|
||||
|
||||
Чтобы выполнить один шаг ядра, попробуйте:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
s
|
||||
....
|
||||
|
||||
При этом будет осуществляться пошаговое выполнение функций, однако вы можете трассировать их с помощью DDB, пока не будет достигнуто соответствие возвращаемому значению:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
n
|
||||
....
|
||||
|
|
@ -443,7 +443,7 @@ options DDB
|
|||
|
||||
Чтобы выводить значения в памяти, используйте, (к примеру):
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
x/wx 0xf0133fe0,40
|
||||
x/hd db_symtab_space
|
||||
|
|
@ -453,14 +453,14 @@ options DDB
|
|||
|
||||
для доступа к данным типа слово/полуслово/байт и вывода в шестнадцатеричном/десятичном/символьном виде. Число после запятой означает счетчик объектов. Чтобы вывести следующие 0x10 объектов, просто укажите:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
x ,10
|
||||
....
|
||||
|
||||
Подобным же образом используйте
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
x/ia foofunc,10
|
||||
....
|
||||
|
|
@ -469,7 +469,7 @@ options DDB
|
|||
|
||||
Чтобы изменить значения в памяти, используйте команду write:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
w/b termbuf 0xa 0xb 0
|
||||
w/w 0xf0010030 0 0
|
||||
|
|
@ -479,28 +479,28 @@ options DDB
|
|||
|
||||
Если вам нужно узнать текущее содержимое регистров, используйте:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
show reg
|
||||
....
|
||||
|
||||
Альтернативно вы можете вывести содержимое одного регистра по команде, скажем,
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
p $eax
|
||||
....
|
||||
|
||||
и изменить его по:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
set $eax new-value
|
||||
....
|
||||
|
||||
Если вам нужно вызвать некоторую функцию ядра из DDB, просто укажите:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
call func(arg1, arg2, ...)
|
||||
....
|
||||
|
|
@ -509,28 +509,28 @@ options DDB
|
|||
|
||||
Для вывода суммарной статистики по всем работающим процессам в стиле команды man:ps[1] воспользуйтесь такой командой:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
ps
|
||||
....
|
||||
|
||||
Теперь вы узнали, почему ядро работает с ошибками и хотите выполнить перезагрузку. Запомните, что в зависимости от влияния предыдущих ошибок, не все части ядра могут работать так, как ожидается. Выполните одно из следующих действий для закрытия и перезагрузки вашей системы:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
panic
|
||||
....
|
||||
|
||||
Это приведет к созданию дампа ядра и перезагрузке, так что позже вы можете проанализировать дамп на более высоком уровне при помощи `gdb`. Как правило, эта команда должна следовать за другой командой `continue`.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
call boot(0)
|
||||
....
|
||||
|
||||
Это может оказаться хорошим способом для корректного закрытия работающей системы, `sync()` для всех дисков и напоследок перезагрузка. Пока интерфейсы диска и файловой системы в ядре не повреждены, это может быть самым правильным способом закрытия системы.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
call cpu_reset()
|
||||
....
|
||||
|
|
@ -539,7 +539,7 @@ options DDB
|
|||
|
||||
Если вам нужен краткий справочник по командам, просто наберите:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
help
|
||||
....
|
||||
|
|
@ -555,7 +555,7 @@ options DDB
|
|||
|
||||
Вы должны настроить исследуемое ядро при помощи команды `config -g`, включить `DDB` в конфигурацию и откомпилировать его обычным образом. Это даст большой бинарный файл из-за отладочной информации. Скопируйте это ядро на целевую машину, усеките отладочную информацию командой `strip -x` и загрузите это ядро с использованием параметра загрузки `-d`. Подключите последовательный канал целевой машины, имеющий установленные флаги "flags 080" на соответствующем устройстве sio к любому последовательному каналу отладочного хоста. А теперь на отладочной машине перейдите в каталог компиляции целевого ядра и запустите `gdb`:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% gdb -k kernel
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
|
|
@ -568,14 +568,14 @@ Copyright 1996 Free Software Foundation, Inc...
|
|||
|
||||
Проинициализируйте сеанс удаленной отладки (предполагается, что используется первый последовательный порт) такой командой:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(kgdb) target remote /dev/cuaa0
|
||||
....
|
||||
|
||||
Теперь на целевом хосте (тот, который перешел в DDB даже до начала процесса обнаружения устройств) наберите:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
|
|
@ -585,14 +585,14 @@ db> gdb
|
|||
|
||||
DDB ответит следующим:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Next trap will enter GDB remote protocol mode
|
||||
....
|
||||
|
||||
Каждый раз, когда вы будете набирать `gdb`, режим будет меняться между удаленным GDB и локальным DDB. Чтобы немедленно вызвать следующее прерывание, просто наберите `s` (step). Ваш хостирующий GDB получит управление над целевым ядром:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
|
|
@ -609,7 +609,7 @@ Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
|||
|
||||
Первым делом вам нужно построить модуль (или модули) с включением отладочной информации:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# cd /sys/modules/linux
|
||||
# make clean; make COPTS=-g
|
||||
|
|
@ -617,7 +617,7 @@ Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
|||
|
||||
Если вы используете GDB в режиме удаленного доступа, то для определения того, куда был загружен модуль, можете запустить команду `kldstat` на целевой машине:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# kldstat
|
||||
Id Refs Address Size Name
|
||||
|
|
@ -631,7 +631,7 @@ Id Refs Address Size Name
|
|||
|
||||
Затем вам нужно определить смещение текстового сегмента модуля:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# objdump --section-headers /sys/modules/linux/linux.ko | grep text
|
||||
3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2
|
||||
|
|
@ -640,7 +640,7 @@ Id Refs Address Size Name
|
|||
|
||||
То, что вы ищете, является секцией `.text`, в примере выше это секция 10. Четвертое числовое поле (всего шестое по счёту) является смещением текстовой секции внутри файла. Добавьте это смещение к адресу загрузки, чтобы получить адрес, на который был перемещён код модуля. В нашем примере мы получим 0xc0adc000 + 0x62d0 = c0ae22d0. Воспользуйтесь командой `add-symbol-file` в GDB для указания отладчику на модуль:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(kgdb) add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0
|
||||
add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0?
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue