Обработка исключений процессора Intel

На процессорах архитектуры Intel IA-32 и Intel 64 присваивается каждое архитектурно определенное исключение, уникальный идентификационный номер вызвал вектор. Процессор использует вектор, присвоенный исключению как индекс в таблицу дескрипторов прерываний (IDT). IDT обеспечивает точку входа для обработчика исключений. Некоторые регистры процессора сохранены на штабеле, прежде чем управление будет передано обработчику исключений.

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

Наиболее распространенные исключения:

• Отсутствия страницы, вызванные попыткой получить доступ к данным в недопустимом адресе памяти, таком как разыменование Указателя Нулевого.

• Недопустимые/неопределенные исключения кода операции, вызванные попыткой выполнить инструкцию с недопустимым кодом операции.

• Общие нарушения защиты, вызванные любым из многих условий, включая передачу выполнения к сегменту неисполняемого кода или записи или в сегмент кода или в сегмент данных только для чтения.

Подробные данные об обработке исключений на процессорах Intel могут быть сочтены в Главе 5 «Обработкой прерываний и Обработкой исключений» документа Руководством Разработчика программного обеспечения Архитектуры Intel 64 и IA-32, Объем 3 А: Системное Руководство по программированию, Часть 1.

Регистры процессора, показанные в паническом журнале:

• Control Register 0 (CR0). Содержит флаги, управляющие рабочим режимом процессора и указывающие состояние процессора.

• Control Register 2 (CR2). Содержит адрес, вызвавший отсутствие страницы.

• Control Register 3 (CR3). Содержит физический адрес основы каталога страницы.

• Control Register 4 (CR4). Содержит группу флагов, включающих несколько архитектурных расширений и указывающих поддержку операционной системы определенных возможностей процессора.

• EAX. Регистр общего назначения, также используемый в качестве аккумулятора для операндов и данных результатов.

• EBX. Регистр общего назначения, также используемый в качестве указателя на данные в сегменте DS.

• ECX. Регистр общего назначения, также используемый в качестве счетчика для строки и операций цикла.

• EDX. Регистр общего назначения, также используемый в качестве указателя I/O.

• EBP. Регистр общего назначения, в основном используемый в качестве указателя на данные по штабелю (стековый фрейм).

• ESI. Регистр общего назначения, используемый в качестве указателя на данные в сегменте, на который указывает DS, регистрируется и как исходный указатель для строковых операций.

• EDI. Регистр общего назначения, используемый в качестве указателя на данные (или место назначения) в сегменте, на который указывает ES, регистрируется и как целевой указатель для строковых операций.

• EFLAGS. Регистр состояния Program и регистр управления. Содержит состояние, управление и системные флаги. Флаги состояния установлены, поскольку результат выдерживает сравнение и арифметические операции. Этот регистр выведен на экран в панике как EFL.

• Указатель команд (EIP). Содержит адрес следующей инструкции, которая будет выполняться. В зависимости от исключения это может быть адресом инструкции, вызвавшей исключение или следующую инструкцию в процессе выполнения программы.

• CS. Сегментный регистр, указывающий на сегмент кода.

• DS. Сегментный регистр, указывающий на сегмент данных.

Подробные данные о наборах регистров Intel 64 и IA-32 могут быть сочтены в Главе 3 «Основной Средой выполнения» документа Руководством Разработчика программного обеспечения Архитектуры Intel 64 и IA-32, Объем 1: Базовая архитектура.

Ядро Mac OS X следует за этим потоком выполнения при обработке исключения Intel 64 или IA-32:

1. xnu/osfmk/i386/idt64.s: master_idt

   (xnu/osfmk/i386/idt.s: master_idt на процессорах Core Duo)

2. xnu/osfmk/i386/locore.s: lo_alltraps

   Каждый обработчик исключений в IDT в конечном счете переходит к lo_alltraps

3. xnu/osfmk/i386/locore.s: trap_from_kernel

4. xnu/osfmk/i386/trap.c: kernel_trap

5. xnu/osfmk/i386/trap.c: panic_trap

6. xnu/osfmk/kern/debug.c: panic

7. xnu/osfmk/i386/AT386/model_dep.c: Debugger

8. xnu/osfmk/i386/AT386/model_dep.c: panic_i386_backtrace

Функции panic_trap и panic_i386_backtrace произведите панический журнал.

Обработка исключений процессора PowerPC

Семейство микропроцессоров PowerPC обрабатывает исключения путем переключения на состояние супервизора, сохранения состояния процессора к определенным регистрам, и затем перехода к подпрограмме обработчика исключений. Каждый главный тип исключения (доступ памяти данных, выравнивание, и т.д.) имеет свой собственный вектор исключения, расположенный в абсолютном адресе, определенном в архитектуре PowerPC.

Наиболее распространенные исключения:

• DSI (прерывание хранения данных или доступ памяти данных) исключения, вызванные попыткой получить доступ к данным в недопустимом адресе памяти, таком как разыменование Указателя Нулевого.

• ISI (прерывание хранения инструкции) исключения, вызванные попыткой выполнить инструкцию в недопустимом адресе памяти, таком как ветвление к нулю расположения.

• Исключения запрещенной команды, вызванные попыткой выполнить инструкцию с недопустимым кодом операции.

Подробные данные об обработке исключений PowerPC могут быть найдены в Главе 6 Семейства микропроцессоров PowerPC документа: Среды программирования Для 32-разрядных Микропроцессоров (в дальнейшем именуемый TPE).

Регистры процессора, показанные в паническом журнале:

• DSISR. Идентифицирует причину DSI и исключений выравнивания, таких как исключение ошибки прямого хранилища, или операнд целочисленной загрузки двойного слова или инструкции хранилища не выравнивается словом.

• Data Access Register (DAR). Содержит исполнительный адрес элемента памяти, вызвавшего исключение выравнивания или DSI.

• Machine State Register (MSR). Определяет состояние процессора. Настройки включают разрешение прерывания, уровень полномочий, машинный контроль включают, и биты преобразования адресов.

• Состояние машины Регистр Save/Restore 0 (SRR0). Содержит адрес, используемый для вычисления, где обработка инструкции должна продолжаться после того, как исключение обрабатывается. В зависимости от исключения это может быть исполнительным адресом инструкции, вызвавшей исключение или следующую инструкцию в процессе выполнения программы. Этот регистр выведен на экран в панике как PC (счетчик команд).

• Состояние машины Регистр Save/Restore 1 (SRR1). Содержит специфичную для исключения информацию и выбранные биты от MSR в то время, когда произошло исключение. Этот регистр выведен на экран в панике как MSR.

• Link Register (LR). Содержит адрес инструкции после последнего вызова подпрограммы (bl: перейдите тогда соединяются), инструкция.

• General Purpose Register 1 (GPR1). Используемый в качестве указателя вершины стека для хранения параметров и других временных элементов данных. Этот регистр выведен на экран в панике как R1.

Подробные данные о наборе регистров PowerPC могут быть найдены в Главе 2 TPE.

Ядро Mac OS X следует за этим потоком выполнения при обработке исключения PowerPC:

1. xnu/osfmk/ppc/lowmem_vectors.s: L_handlerXXXX

   (где XXXX вектор обработчика исключений в диапазоне 100 к 2FFF; только 100-2000 в настоящее время используются),

2. xnu/osfmk/ppc/lowmem_vectors.s: L_exception_entry

3. xnu/osfmk/ppc/hw_exception.s: thandler

4. xnu/osfmk/ppc/trap.c: trap

5. xnu/osfmk/ppc/trap.c: unresolved_kernel_trap

Последняя функция (unresolved_kernel_trap) то, где паническая информация выведена на экран.

Как считать панический журнал из основанного на Intel Mac

Перечисление 1 является типичным паническим дисплеем от основанного на Intel компьютера Macintosh рабочий Mac OS X 10.5.4. Номера строки были добавлены для простоты ссылки.

  Пример перечисления 1 Intel пугает журнал.

1 panic(cpu 0 caller 0x001A8CD4): Kernel trap at 0x223ab275, type 14=page fault, registers:
2 CR0: 0x8001003b, CR2: 0xdeadbeef, CR3: 0x01251000, CR4: 0x00000660
3 EAX: 0xdeadbeef, EBX: 0x0049be30, ECX: 0x0050d444, EDX: 0x00534da0
4 CR2: 0xdeadbeef, EBP: 0x220dbe48, ESI: 0x06d59600, EDI: 0x02cecd00
5 EFL: 0x00010206, EIP: 0x223ab275, CS: 0x00000008, DS: 0x032f0010
6 Error code: 0x00000002
7 
8 Backtrace, Format - Frame : Return Address (4 potential args on stack) 
9 0x220dbc48 : 0x12b0fa (0x4592a4 0x220dbc7c 0x133243 0x0) 
10 0x220dbc98 : 0x1a8cd4 (0x46280c 0x223ab275 0xe 0x461fbc) 
11 0x220dbd78 : 0x19ede5 (0x220dbd90 0x2cecd00 0x220dbe48 0x223ab275) 
12 0x220dbd88 : 0x223ab275 (0xe 0x48 0x61330010 0x31340010) 
13 0x220dbe48 : 0x410db2 (0x6d59600 0x2cecd00 0x13315e 0x1331fa) 
14 0x220dbea8 : 0x412c47 (0x2cecd00 0x6d59600 0x49be30 0x1) 
15 0x220dbf28 : 0x4124ab (0x2cecd00 0x3312740 0x0 0x3f05c9) 
16 0x220dbf78 : 0x411127 (0x2cecd00 0x8 0x220dbfac 0x1) 
17 0x220dbfc8 : 0x19ebdc (0x30db910 0x0 0x1a20b5 0x3b3e5d0) 
18 Backtrace terminated-invalid frame pointer 0
19 Kernel loadable modules in backtrace (with dependencies):
20 com.apple.dts.driver.PanicDriver(1.1)@0x223aa000->0x223abfff
21
22 BSD process name corresponding to current thread: kernel_task
23
24 Mac OS version:
25 9E17
26
27 Kernel version:
28 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386
29 System model name: MacPro1,1 (Mac-F4208DC8)
30 ethernet MAC address: 00:17:f2:00:00:00
31 ip address: 192.0.2.1
32 
33 Waiting for remote debugger connection.

Для каждой строки панического журнала, имя исходного файла ядра и функции, выводящей на экран ту строку, дается, сопровождается объяснением информации о той строке.

Строка 1: xnu/osfmk/i386/trap.c: panic_trap

panic(: Это вызовы функции panic вывести на экран его вывод.

cpu 3: Число вызвавшего ядра процессора panic. Обратите внимание на то, что в многожильной системе для одного ядра возможно быть испуганным, в то время как другие продолжают работать.

caller 0x001A8CD4):: Адрес тот, от который panic был вызван. Если паника будет результатом необработанного исключения процессора, то этот адрес будет в panic_trap функция.

Kernel trap at 0x223ab275: Текстовое описание причины паники и адреса инструкции, выполнявшейся во время паники.

Type 14=page fault: имя прерывания. Это - текстовое описание исключения. Имена прерывания найдены в массиве trap_type в xnu/osfmk/i386/trap.c, который инициализируется от макроса TRAP_NAMES найденный в соответствующем заголовочном файле xnu/osfmk/i386/trap.h. Вектор исключения процессора trapno (определенный в xnu/osfmk/i386/trap.h) первоначально продвинут на штабель обработчиком исключений, на который указывает IDT (см. xnu/osfmk/i386/idt64.s и xnu/osfmk/i386/idt.s).

14 вначале вектор исключения в десятичном числе. Используя это значение можно искать подробные данные об определенном исключении в Руководстве Разработчика программного обеспечения Архитектуры Intel 64 и IA-32, Объем 3 А: Системное Руководство по программированию, Глава 5 Части 1.

Назад к перечислению 1

Строка 2: xnu/osfmk/i386/trap.c: panic_trap

Содержание регистров CR0, CR2, CR3, и CR4 в то время, когда панический журнал сгенерирован.

Назад к перечислению 1

Строка 3: xnu/osfmk/i386/trap.c: panic_trap

Содержание регистров EAX, EBX, ECX, и EDX от обработчика исключений.

Назад к перечислению 1

Строка 4: xnu/osfmk/i386/trap.c: panic_trap

Содержание регистров CR2, EBP, ESI, и EDI от обработчика исключений.

Назад к перечислению 1

Строка 5: xnu/osfmk/i386/trap.c: panic_trap

Содержание регистров EFLAGS, EIP, CS, и DS от обработчика исключений.

Назад к перечислению 1

Строка 6: xnu/osfmk/i386/trap.c: panic_trap

Error code: 0x00000002: О коде ошибки сообщают для каждого исключения, связанного с определенным сегментом. Формат кода ошибки для отсутствия страницы (вектор исключения 14) отличается от этого для других исключений. Код ошибки отсутствия страницы сообщает, был ли отказ вызван не - существующая страница или некоторая другая причина и был ли доступ к памяти чтением или записью. См. Руководство Разработчика программного обеспечения Архитектуры Intel 64 и IA-32, Объем 3 А: Системное Руководство по программированию, Раздел Части 1 5.3 для подробных данных.

Значения кодов распространенной ошибки для вектора исключения 14 0x00000000 указание чтения от несуществующей страницы, и 0x00000002 указание записи к несуществующей странице.

Назад к перечислению 1

Строка 7: xnu/osfmk/kern/debug.c: panic

Строка 8: xnu/osfmk/i386/AT386/model_dep.c: panic_i386_backtrace

Это - фактический след штабеля. Каждая строка показывает адрес стекового фрейма, двоеточия «:», обратный адрес, сохраненный в том кадре, тогда четыре потенциальных параметра в стековом фрейме, включается в круглые скобки.

Первый стековый фрейм расположен с помощью значения указателя вершины стека (EBP) в то время, когда след получен. Следующий стековый фрейм расположен с помощью значения EBP сохраненный в стековом фрейме. Если с нулевым указателем вершины стека встретятся, до 16 стековых фреймов будут показаны, меньше, чем это.

Подробные данные о том, как штабель используется Mac OS X, могут быть сочтены в OS X документа Руководством по Вызову функции ABI.

След обычно является наиболее полезной информацией в паническом журнале, потому что это может использоваться для восстановления цепочки вызовов, приведшей к исключению. Это обсуждено в следующем разделе Isolating the Crash.

Назад к перечислению 1

Строки 9 - 18: xnu/osfmk/i386/AT386/model_dep.c: panic_i386_backtrace

Назад к перечислению 1

Строка 19: xnu/osfmk/kern/kmod.c: kmod_dump_to

Это смотрит на адреса в следе и распечатывает имя модуля, версию и начальные и конечные адреса каждого загружаемого модуля ядра в следе. (Загружаемый модуль ядра является просто исполнимой частью расширения ядра или KEXT.) Это также распечатывает ту же информацию для зависимостей каждого расширения ядра. Имя модуля и версия совпадают с показанным kextstat команда и является значением MODULE_NAME и MODULE_VERSION в XCode создают настройки. Зависимости - указанные в OSBundleLibraries свойство в KEXT's Info.plist список свойств.

Назад к перечислению 1

Строка 20: xnu/osfmk/kern/kmod.c: kmod_dump_to

Назад к перечислению 1

Строка 21: xnu/osfmk/kern/debug.c: panic_display_process_name

Строка 22: xnu/osfmk/kern/debug.c: panic_display_process_name

Если текущий поток, порожденный из ядра, показанное имя задачи, kernel_task.

Назад к перечислению 1

Строка 23: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 24: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 25: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Номер сборки получен из глобальной переменной ядра osversion.

Назад к перечислению 1

Строка 26: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Назад к перечислению 1

Строка 27: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 28: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Это - значение глобальной переменной ядра version, набор в это время ядро создается.

Строка Mon Jun 9 19:30:53 PDT 2008 дата и время, ядро было создано. Строка xnu-1228.5.20~1 исходная версия, используемая для создания этого ядра. Эта информация может использоваться для определения местоположения источника для этой версии ядра в Дарвинском открытом исходном коде.

Для наблюдения версии рабочего ядра используйте sysctl команда, как проиллюстрировано в Перечислении 2.

Перечисление 2  , Выводящее на экран версию ядра.

$ sysctl kern.version kern.version = Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53 PDT 2008; root:xnu-1220.5.20~1/RELEASE_I386

Шаги для создания пользовательского ядра могут быть сочтены в главе Создающими и Отлаживающими Ядрами Руководства по программированию Ядра документа.

Назад к перечислению 1

Строка 29: xnu/osfmk/kern/debug.c: panic_display_model_name

Имя модели дает высокоуровневое описание испуганной системы. Первая часть MacPro1,1 содержит название продукта и версию. Если панический журнал отправляется Apple, вторая часть только полезна.

Назад к перечислению 1

Строка 30: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

Это - встроенный MAC-адрес Ethernet испуганной машины. Это и IP-адрес (строка 31) используются для установления удаленного сеанса отладки.

Назад к перечислению 1

Строка 31: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

Это - IP-адрес испуганной машины. Это и MAC-адрес Ethernet (строка 30) используются для установления удаленного сеанса отладки.

Назад к перечислению 1

Строка 32: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

Строка 33: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

В этой точке система ожидает соединения от удаленного отладчика.

Назад к перечислению 1

Как считать панический журнал из основанного на PowerPC Mac

Перечисление 3 является типичным паническим дисплеем от основанного на PowerPC компьютера Macintosh рабочий Mac OS X 10.5.4. Номера строки были добавлены для простоты ссылки.

  PowerPC перечисления 3 В качестве примера пугает журнал.

1 Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x00000000DEADBEEF PC=0x000000001918F504
2 Latest crash info for cpu 0:
3 Exception state (sv=0x1a85d500)
4 PC=0x1918F504; MSR=0x00009030; DAR=0xDEADBEEF; DSISR=0x42000000; LR=0x1918F4F0; R1=0x19997C50; XCP=0x0000000C (0x300 - Data access)
5 Backtrace:
6 0x1918F4F0 0x0034380C 0x00344960 0x00346810 0x00345930 0x000B05D4 
7 Kernel loadable modules in backtrace (with dependencies):
8 com.apple.dts.driver.PanicDriver(1.1)@0x1918e000->0x1918ffff
9 Proceeding back via exception chain:
10 Exception state (sv=0x1a85d500)
11 previously dumped as "Latest" state. skipping...
12 Exception state (sv=0x19f2ac80)
13 PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)
14
15 BSD process name corresponding to current thread: kernel_task
16
17 Mac OS version:
18 9E17
19
20 Kernel version:
21 Darwin Kernel Version 9.4.0: Mon Jun  9 19:36:17 PDT 2008; root:xnu-1228.5.20~1/RELEASE_PPC
22 System model name: PowerMac7,2
23 Memory access exception (1,0,0)
24 ethernet MAC address: 00:0a:95:00:00:00
25 ip address: 192.0.2.2
26 
27 Waiting for remote debugger connection.

Для каждой строки панического журнала, имя исходного файла ядра и функции, выводящей на экран ту строку, дается, сопровождается объяснением информации о той строке.

Строка 1: xnu/osfmk/ppc/trap.c: unresolved_kernel_trap

Unresolved kernel trap: Текстовое описание причины паники.

(cpu 0): Число ядра процессора, на котором произошло исключение. Обратите внимание на то, что в многожильной системе для одного ядра возможно быть испуганным, в то время как другие продолжают работать.

0x300 - Data access: имя прерывания. Это - текстовое описание исключения. Имена прерывания найдены в массиве trap_type в xnu/osfmk/ppc/trap.c. Аппаратный код исключения trapno (определенный в xnu/osfmk/ppc/exception.h) первоначально установлен обработчиком исключений xnu/osfmk/ppc/lowmem_vectors.s: L_handlerXXXX где XXXX вектор исключения PowerPC. Индекс в trap_type массив вычислен путем деления trapno T_VECTOR_SIZE, определенный, чтобы быть 4 (размер указателя функции), также в xnu/osfmk/ppc/exception.h.

0x300 вначале вектор исключения PowerPC. Используя это значение можно искать подробные данные об определенном исключении в Главе 6 TPE.

DAR: содержание Регистра Доступа к данным

PC: содержание регистра SRR0

Интерпретация DAR и PC варьируется в зависимости от определения каждого исключения.

Назад к перечислению 3

Строка 2: xnu/osfmk/ppc/model_dep.c: print_backtrace

Назад к перечислению 3

Строка 3: xnu/osfmk/ppc/model_dep.c: print_backtrace

Состояния исключения PowerPC сохранены в структурах данных типа savearea (см. xnu/osfmk/ppc/exception.h). sv адрес savearea для последнего исключения.

Назад к перечислению 3

Строка 4: xnu/osfmk/ppc/model_dep.c: dump_savearea

PC: содержание SRR0

MSR: содержание SRR1

DAR: содержание Регистра Доступа к данным

DSISR: содержание DSISR

LR: содержание Регистра Ссылки

R1: содержание GPR1

XCP: Это не регистр, но является кодом исключения, сохраненным в savearea соответствие текущему исключению. Это сопровождается именем прерывания (см. строку 1).

Назад к перечислению 3

Строка 5: xnu/osfmk/ppc/model_dep.c: dump_backtrace

Назад к перечислению 3

Строка 6: xnu/osfmk/ppc/model_dep.c: dump_backtrace

Это - фактический след штабеля. Начальный указатель вершины стека является значением GPR1 в savearea. Значение LR от области связи стекового фрейма распечатано, тогда следующий стековый фрейм расположен с помощью значения GPR1, сохраненного в стековом фрейме. Если с нулем GPR1 встретятся или если a, до 32 стековых фреймов будут распечатаны, меньше, чем это savearea существует для более раннего исключения.

Подробные данные о том, как штабель используется Mac OS X, могут быть сочтены в OS X документа Руководством по Вызову функции ABI.

След обычно является наиболее полезной информацией в паническом дампе, потому что это может использоваться для восстановления цепочки вызовов, приведшей к исключению. Это обсуждено в следующем разделе Isolating the Crash.

Назад к перечислению 3

Строка 7: xnu/osfmk/kern/kmod.c: kmod_dump_to

Это смотрит на адреса в следе и распечатывает имя модуля, версию и начальные и конечные адреса каждого загружаемого модуля ядра в следе. (Загружаемый модуль ядра является просто исполнимой частью расширения ядра или KEXT.) Это также распечатывает ту же информацию для зависимостей каждого расширения ядра. Имя модуля и версия совпадают с показанным kextstat команда и является значением MODULE_NAME и MODULE_VERSION в XCode создают настройки. Зависимости - указанные в OSBundleLibraries свойство в KEXT's Info.plist список свойств.

Назад к перечислению 3

Строка 8: xnu/osfmk/kern/kmod.c: kmod_dump_to

Строка 9: xnu/osfmk/ppc/model_dep.c: print_backtrace

Каждое состояние исключения теперь выводится. Первый был уже показан в строках 3 - 6 (отметьте то же значение sv в обоих расположениях), таким образом, это пропускается.

Назад к перечислению 3

Строка 10: xnu/osfmk/ppc/model_dep.c: print_backtrace

Назад к перечислению 3

Строка 11: xnu/osfmk/ppc/model_dep.c: print_backtrace

Назад к перечислению 3

Строка 12: xnu/osfmk/ppc/model_dep.c: dump_savearea

То же как строка 3.

Назад к перечислению 3

Строка 13: xnu/osfmk/ppc/model_dep.c: dump_savearea

То же как строка 4.

Назад к перечислению 3

Строка 14: xnu/osfmk/kern/debug.c: panic_display_process_name

Строка 15: xnu/osfmk/kern/debug.c: panic_display_process_name

Если текущий поток, порожденный из ядра, показанное имя процесса, kernel_task.

Назад к перечислению 3

Строка 16: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 17: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 18: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Номер сборки получен из глобальной переменной ядра osversion.

Назад к перечислению 3

Строка 19: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 20: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Строка 21: xnu/osfmk/kern/debug.c: panic_display_system_configuration

Это - значение глобальной переменной ядра version, набор в это время ядро создается.

Строка Mon Jun 9 19:36:17 PDT 2008 дата и время, ядро было создано. Строка xnu-1228.5.20~1 исходная версия, используемая для создания этого ядра. Эта информация может использоваться для определения местоположения источника для этой версии ядра в Дарвинском открытом исходном коде.

Для наблюдения версии рабочего ядра используйте sysctl команда, как проиллюстрировано в Перечислении 2.

Шаги для создания пользовательского ядра могут быть сочтены в главе Создающими и Отлаживающими Ядрами Руководства по программированию Ядра документа.

Назад к перечислению 3

Строка 22: xnu/osfmk/kern/debug.c: panic_display_model_name

Имя модели включает название продукта и версию испуганной системы.

Назад к перечислению 1

Строка 23: xnu/osfmk/kdp/kdp_udp.c: kdp_raise_exception

Эта строка содержит сообщение об исключении, сопровождаемое числом исключения, кодом и подкодом в круглых скобках.

exception: Массив kdp_trap_codes определенный в xnu/osfmk/kdp/ml/ppc/kdp_machdep.c используется для преобразования специфичных для PowerPC кодов исключений в универсальные коды исключений Маха, используемые KDB (отладчик ядра). Коды Маха определяются в mach/exception_type.h, но это не обычно полезно, потому что большинство необработанных исключений PowerPC отображается на EXC_BAD_ACCESS (1).

exception_message: Код исключения Маха используется для поиска текстового сообщения, описывающего исключение. Таблица сообщений exception_message определяется в xnu/osfmk/kdp/kdp_udp.c.

code и subcode не используются и всегда нуль.

Назад к перечислению 3

Строка 24: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

Это - встроенный MAC-адрес Ethernet испуганной машины. Это и IP-адрес (строка 25) используются для установления удаленного сеанса отладки.

Назад к перечислению 3

Строка 25: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

Это - IP-адрес испуганной машины. Это и MAC-адрес Ethernet (строка 24) используются для установления удаленного сеанса отладки.

Назад к перечислению 3

Строка 26: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

Строка 27: xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

В этой точке система ожидает соединения от удаленного отладчика.

Назад к перечислению 3

Дешифровка панического журнала от основанного на Intel Mac

В нашем примере исключение отсутствия страницы произошло с указателем команд, содержащим 0x223ab275. Смотря на список загруженных расширений ядра, самое близкое соответствие com.apple.dts.driver.PanicDriver который расположен между адресами 0x223aa000 и 0x223abfff. Затем потому что это - отсутствие страницы, CR2 содержит адрес, к которому нельзя было получить доступ, и код ошибки описывает причину отсутствия страницы. В этом случае это была попытка записать в память в 0xdeadbeef это инициировало исключение.

Расширения ядра и расширения ядра в рабочей системе Mac OS X содержат как раз достаточно символьной информации для разрешения зависимостей между ними. Для перевода всех обратных адресов в коде ядра Mac OS X загрузите Кернеля Дебуга Кита, соответствующего версии и сборке Mac OS X в испуганной системе. Наборы Кернеля Дебуга содержат богатые символом версии ядра и многих семей I/O Kit. Смонтируйте образ диска Кернеля Дебуга Кита, и Вы готовы пойти.

Ваши собственные расширения ядра будут уже иметь число сплошной линии и информацию об имени функции, если они были созданы с помощью конфигурации Отладочной сборки XCode. На Mac OS X 10.5 и позже, быть уверен Debug Information Format установка сборки в Ваших целевых настройках XCode установлена в DWARF with dSYM File.

Генерация файлов символов сделана с помощью kextload команды, как проиллюстрировано в Перечислении 4. -s опция указывает каталог, где записать файлы символов. -n причины опции kextload запрашивать адрес загрузки каждого расширения ядра и его зависимостей.

Также можно использовать createsymbolfiles сценарий, включенный как часть каждого Кернеля Дебуга Кита для упрощения генерации файла символов как показано в Перечислении 5.

Перечисление 4  , Генерирующее файл символов с помощью kextload.

localhost:~ me$ kextload -c -e -k /Volumes/KernelDebugKit/mach_kernel -n -z -r /Volumes/KernelDebugKit/ -s /tmp PanicDriver/build/Debug/PanicDriver.kext/
kextload: notice: extension PanicDriver/build/PanicDriver.kext/ has debug properties set
enter the hexadecimal load addresses for these modules:
com.apple.dts.driver.PanicDriver: 0x223aa000

Перечисление 5  , Генерирующее файл символов с помощью createsymbolfiles.

localhost:~ me$ /Volumes/KernelDebugKit/createsymbolfiles -s /tmp PanicDriver/build/Debug/PanicDriver.kext
kextload: notice: extension PanicDriver/build/PanicDriver.kext/ has debug properties set
enter the hexadecimal load addresses for these modules:
com.apple.dts.driver.PanicDriver: 0x223aa000

Это приводит к отдельному файлу символов для каждого модуля в /tmp, именованный <module-name>.sym.

Затем, запустите GDB и загрузите файлы символов с помощью add-kext команда, как продемонстрировано в Перечислении 6. set kext-symbol-file-path команда говорит GDB, где искать .sym файлы символов. По умолчанию GDB будет искать файлы символов в том же каталоге как KEXT быть загруженным add-kext.

Перечисление 6  , Загружающее файл символов в GDB.

localhost:~ me$ gdb /Volumes/KernelDebugKit/mach_kernel
GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 10 10:38:33 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...
(gdb) set kext-symbol-file-path /tmp
(gdb) add-kext PanicDriver/build/Debug/PanicDriver.kext
add symbol table from file "/tmp/com.apple.dts.driver.PanicDriver.sym" (y or n) y
Reading symbols from /private/tmp/com.apple.dts.driver.PanicDriver.sym...Reading symbols from PanicDriver/build/Debug/PanicDriver.kext.dSYM/
  Contents/Resources/DWARF/PanicDriver...done.
done.
(gdb)

Повторитесь add-kext команда для каждой из зависимостей Вашего KEXT как показано в паническом журнале.

Если Ваш проект сконфигурирован для создания stabs отладочная информация вместо DWARF, используйте add-symbol-file команда вместо этого как показано в Перечислении 7. stabs отладочной информацией было значение по умолчанию в системах, более старых, чем Mac OS X 10,5 Leopard.

Перечисление 7  , Загружающее файл символов в GDB при использовании отладочной информации ударов.

localhost:~ me$ gdb /Volumes/KernelDebugKit/mach_kernel
GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...
(gdb) add-symbol-file /tmp/com.apple.dts.driver.PanicDriver.sym
add symbol table from file "/tmp/com.apple.dts.driver.PanicDriver.sym" at
(y or n) y
Reading symbols from /tmp/com.apple.dts.driver.PanicDriver.sym...done.
(gdb)

В случае имен функций C++ Набора I/O можно счесть полезным не исказить имена для создания их более читаемыми. Команда set print asm-demangle on удобный способ сделать это. Эта команда управляет demangling C++ и имен Objective C в списках дизассемблирования.

Выведите на экран инструкцию, расположенную в указателе команд (EIP) с помощью, «исследуют память как инструкцию» команда x/i <address>. В зависимости от типа исключения это или будет инструкцией, сразу вызвавшей исключение или то после. Пример показан в Перечислении 8.

  Разборка перечисления 8 от указателя команд.

(gdb) set print asm-demangle on (gdb) x/i 0x223ab275 0x223ab275 <com_apple_dts_driver_PanicDriver::start(IOService*)+77>: movl   $0x7fff,(%eax) (gdb)

Затем, для каждого обратного адреса в следе, демонтируйте функцию, содержащую тот адрес с помощью команды disass <address>. Перечисление 9 показывает результаты разборки следа, показанного в Перечислении 1.

Перечисление 9  , Декодирующее след.

(gdb) disass 0x12b0fa
Dump of assembler code for function panic:
0x0012af54 <panic+0>: push   %ebp
...
0x0012b0f5 <panic+417>: call   0x1ae39f <Debugger>
0x0012b0fa <panic+422>: mov    0x4d5278,%eax
...

(gdb) disass 0x1a8cd4
Dump of assembler code for function kernel_trap:
0x001a872a <kernel_trap+0>: push   %ebp
...
0x001a8ccf <kernel_trap+1445>: call   0x12af54 <panic>
0x001a8cd4 <kernel_trap+1450>: add    $0xcc,%esp
...

(gdb) disass 0x19ede5
Dump of assembler code for function trap_from_kernel:
0x0019edcb <trap_from_kernel+0>: mov    %esp,%eax
...
0x0019ede0 <trap_from_kernel+21>: call   0x1a872a <kernel_trap>
0x0019ede5 <trap_from_kernel+26>: mov    %edi,%esp
...

(gdb) disass 0x223ab275
Dump of assembler code for function _ZN32com_apple_dts_driver_PanicDriver5startEP9IOService:
0x223ab228 <com_apple_dts_driver_PanicDriver::start(IOService*)+0>: push   %ebp
...
0x223ab272 <com_apple_dts_driver_PanicDriver::start(IOService*)+74>: mov -0xc(%ebp),%eax
0x223ab275 <com_apple_dts_driver_PanicDriver::start(IOService*)+77>: movl   $0x7fff,(%eax)
...

(gdb) disass 0x410db2
Dump of assembler code for function _ZN9IOService14startCandidateEPS_:
0x00410d3c <IOService::startCandidate(IOService*)+0>: push   %ebp
...
0x00410dac <IOService::startCandidate(IOService*)+112>: call   *0x2cc(%eax)
0x00410db2 <IOService::startCandidate(IOService*)+118>: xor    %edx,%edx
...

(gdb) disass 0x412c47
Dump of assembler code for function _ZN9IOService15probeCandidatesEP12OSOrderedSet:
0x004125a8 <IOService::probeCandidates(OSOrderedSet*)+0>: push   %ebp
...
0x00412c41 <IOService::probeCandidates(OSOrderedSet*)+1689>: call   *0x3c4(%eax)
0x00412c47 <IOService::probeCandidates(OSOrderedSet*)+1695>: mov    %al,-0x3a(%ebp)
...

(gdb) disass 0x4124ab
Dump of assembler code for function _ZN9IOService14doServiceMatchEm:
0x00412334 <IOService::doServiceMatch(unsigned long)+0>: push   %ebp
...
0x004124a5 <IOService::doServiceMatch(unsigned long)+369>: call   *0x3c0(%eax)
0x004124ab <IOService::doServiceMatch(unsigned long)+375>: mov (%ebx),%eax
...

(gdb) disass 0x411127
Dump of assembler code for function _ZN15_IOConfigThread4mainEPS_:
0x00411016 <_IOConfigThread::main(_IOConfigThread*)+0>: push   %ebp
...
0x00411121 <_IOConfigThread::main(_IOConfigThread*)+267>: call   *0x3d4(%edx)
0x00411127 <_IOConfigThread::main(_IOConfigThread*)+273>: jmp    0x411142 <_IOConfigThread::main(_IOConfigThread*)+300>
...

(gdb) disass 0x19ebdc
Dump of assembler code for function call_continuation:
0x0019ebc0 <call_continuation+0>: mov    0x4(%esp),%eax
...
0x0019ebda <call_continuation+26>: call   *%eax
0x0019ebdc <call_continuation+28>: add    $0x10,%esp
...

(gdb)

Тогда найдите функцию, содержащую инструкцию, на которую указывает указатель команд. В этом примере это - функция com_apple_dts_driver_PanicDriver::start начало в адресе 0x223ab228. Так как сохраненный указатель команд от отсутствия страницы обычно указывает на инструкцию, генерировавшую исключение, movl инструкция в 0x223ab275 подозреваемый. Инструкция пытается записать значение 0x7fff к адресу, которым указывают EAX. Панический журнал показывает EAX содержит значение недопустимого указателя 0xdeadbeef, который объясняет причину исключения отсутствия страницы. Этот диагноз является соответствующим более раннему результату разборки единственной инструкции, расположенной в указателе команд.

Также исследуйте другие демонтированные функции, ища инструкцию сразу перед адресом от следа. Обратите внимание на то, что эта инструкция должна быть некоторой формой команды перехода. Для понимания почему вспомните, что след является перечислением обратных адресов, сохраненных до выполнения вызова функции. Если дизассемблирование показывает что-то другое, чем команда перехода, это - подсказка, что Вы могли не генерировать свой файл символов правильно, или что версия операционной системы или Кернеля Дебуга Кита не соответствует испуганную машину. (Эта инструкция не применяется к листовой функции, содержащей инструкцию, генерировавшую исключение.)

Другой удобный метод должен использовать, «исследуют память как инструкцию» команда для разборки инструкций около адреса от следа как в Перечислении 10.

Перечисление 10  , Демонтирующее блок инструкций.

(gdb) x/16i 0x19ebdc-32
0x19ebbc <thread_exception_return+12>: add    %eax,(%eax)
0x19ebbe <thread_exception_return+14>: add    %dl,0x424448b(%eax)
0x19ebc4 <call_continuation+4>: mov    0x8(%esp),%edx
0x19ebc8 <call_continuation+8>: mov    0xc(%esp),%ecx
...
0x19ebd9 <call_continuation+25>: push   %edx
0x19ebda <call_continuation+26>: call   *%eax
0x19ebdc <call_continuation+28>: add    $0x10,%esp
0x19ebdf <call_continuation+31>: mov    %gs:0x4,%eax
...

Одна вещь знать при использовании этого метода состоит в том, что первые несколько инструкций могут не быть корректными, потому что дизассемблирование, вероятно, начнется посреди инструкции.

Дешифровка панического журнала от основанного на PowerPC Mac

В нашем примере исключение доступа к данным произошло со счетчиком команд, содержащим 0x1918F504. Смотря на список загруженных расширений ядра, самое близкое соответствие com.apple.dts.driver.PanicDriver который расположен между адресами 0x1918e000 и 0x1918ffff. Затем потому что это - исключение доступа к данным, DAR содержит адрес, к которому нельзя было получить доступ. В этом случае это была попытка получить доступ к памяти в 0xdeadbeef это инициировало исключение.

Расширения ядра и расширения ядра в рабочей системе Mac OS X содержат как раз достаточно символьной информации для разрешения зависимостей между ними. Для перевода всех обратных адресов в коде ядра Mac OS X загрузите Кернеля Дебуга Кита, соответствующего версии и сборке Mac OS X в испуганной системе. Наборы Кернеля Дебуга содержат богатые символом версии ядра и многих семей I/O Kit. Смонтируйте образ диска Кернеля Дебуга Кита, и Вы готовы пойти.

Ваши собственные расширения ядра будут уже иметь число сплошной линии и информацию об имени функции, если они были созданы с помощью конфигурации Отладочной сборки XCode. На Mac OS X 10.5 и позже, быть уверен Debug Information Format установка сборки в Ваших целевых настройках XCode установлена в DWARF with dSYM File.

Генерация файлов символов сделана с помощью kextload команды, как проиллюстрировано в Перечислении 11. -s опция указывает каталог, где записать файлы символов. -n причины опции kextload запрашивать адрес загрузки каждого расширения ядра и его зависимостей.

Также можно использовать createsymbolfiles сценарий, включенный как часть каждого Кернеля Дебуга Кита для упрощения генерации файла символов как показано в Перечислении 12.

Перечисление 11  , Генерирующее файл символов с помощью kextload.

localhost:~ me$ kextload -c -e -k /Volumes/KernelDebugKit/mach_kernel -n -z -r /Volumes/KernelDebugKit/ -s /tmp PanicDriver/build/Debug/PanicDriver.kext 
kextload: notice: extension PanicDriver/build/Debug/PanicDriver.kext has debug properties set
enter the hexadecimal load addresses for these modules:
com.apple.dts.driver.PanicDriver: 0x1918e000

Перечисление 12  , Генерирующее файл символов с помощью createsymbolfiles.

localhost:~ me$ /Volumes/KernelDebugKit/createsymbolfiles -s /tmp PanicDriver/build/Debug/PanicDriver.kext
kextload: notice: extension PanicDriver/build/PanicDriver.kext/ has debug properties set
enter the hexadecimal load addresses for these modules:
com.apple.dts.driver.PanicDriver: 0x1918e000

Это приводит к отдельному файлу символов для каждого модуля, названного <module-name>.sym.

Затем, запустите GDB и загрузите файлы символов с помощью add-kext команда, как продемонстрировано в Перечислении 13. set kext-symbol-file-path команда говорит GDB, где искать .sym файлы символов. По умолчанию GDB будет искать файлы символов в том же каталоге как KEXT быть загруженным add-kext.

Перечисление 13  , Загружающее файл символов в GDB.

localhost:~ me$ gdb /Volumes/KernelDebugKit/mach_kernel
GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 18 18:41:56 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...
(gdb) set kext-symbol-file-path /tmp
(gdb) add-kext PanicDriver/build/Debug/PanicDriver.kext 
add symbol table from file "/tmp/com.apple.dts.driver.PanicDriver.sym"? (y or n) y
Reading symbols from /private/tmp/com.apple.dts.driver.PanicDriver.sym...Reading symbols from PanicDriver/build/Debug/PanicDriver.kext.dSYM/
  Contents/Resources/DWARF/PanicDriver...done.
done.
(gdb)

Повторитесь add-kext команда для каждой из зависимостей Вашего KEXT как показано в паническом журнале.

Если Ваш проект сконфигурирован для создания stabs отладочная информация вместо DWARF, используйте add-symbol-file команда вместо этого как показано в Перечислении 14. stabs отладочной информацией было значение по умолчанию в системах, более старых, чем Mac OS X 10,5 Leopard.

Перечисление 14  , Загружающее файл символов в GDB при использовании отладочной информации ударов.

localhost:~ me$ gdb /mach_kernel
GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...
(gdb) add-symbol-file /tmp/com.apple.dts.driver.PanicDriver.sym
add symbol table from file "/tmp/com.apple.dts.driver.PanicDriver.sym" at
(y or n) y
Reading symbols from /tmp/com.apple.dts.driver.PanicDriver.sym...done.
(gdb)

В случае имен функций C++ Набора I/O можно счесть полезным не исказить имена для создания их более читаемыми. Команда set print asm-demangle on удобный способ сделать это. Эта команда управляет demangling C++ и имен Objective C в списках дизассемблирования.

Выведите на экран инструкцию, расположенную в счетчике команд (PC) с помощью, «исследуют память как инструкцию» команда x/i <address>. В зависимости от типа исключения это или будет инструкцией, сразу вызвавшей исключение или то после. Пример показан в Перечислении 15.

  Разборка перечисления 15 от счетчика команд.

(gdb) set print asm-demangle on (gdb) x/i 0x1918F504 0x1918f504 <com_apple_dts_driver_PanicDriver::start(IOService*)+120>: stw     r0,0(r2) (gdb)

Затем, для каждого обратного адреса в следе, выведите на экран инструкцию, расположенную сразу до того адреса с помощью команды x/i <address>-4. Это приведет к имени функции, в которой расположен адрес. Обратите внимание на то, что каждая инструкция, демонтированная от следа, должна быть некоторой формой команды перехода. Для понимания почему вспомните, что след является перечислением обратных адресов, сохраненных до выполнения вызова функции. Если дизассемблирование показывает что-то другое, чем команда перехода, это - подсказка, что Вы могли не генерировать свой файл символов правильно, или что версия операционной системы не является тем же как на испуганной машине.

Перечисление 16 показывает результаты декодирования следа, показанного в Перечислении 3.

Перечисление 16  , Декодирующее след.

(gdb) x/i 0x1918F4F0-4
0x1918f4ec <com_apple_dts_driver_PanicDriver::start(IOService*)+96>: bl      0x1918f56c <com_apple_dts_driver_PanicDriver::start(IOService*)+224>

(gdb) x/i 0x0034380C-4
0x343808 <IOService::startCandidate(IOService*)+188>: bctrl

(gdb) x/i 0x00344960-4
0x34495c <IOService::probeCandidates(OSOrderedSet*)+2228>: bctrl

(gdb) x/i 0x00346810-4
0x34680c <IOService::doServiceMatch(unsigned long)+524>: bctrl

(gdb) x/i 0x00345930-4
0x34592c <_IOConfigThread::main(_IOConfigThread*)+352>: bctrl

(gdb) x/i 0x000B05D4-4
0xb05d0 <Call_continuation+16>: blrl

(gdb)