Изменение конфигурационных файлов

Подробные данные добавления нового файла или модуля в ядро отличаются согласно тому, какая часть ядра содержит файл. Если Вы добавляете новый файл или модуль в часть Маха ядра, необходимо перечислить его в различных файлах в xnu/osfmk/conf. Для части BSD ядра необходимо перечислить его в различных файлах в xnu/bsd/conf. В любом случае процедура является в основном тем же, только в различном каталоге.

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

OPTIONS/mach_foo    optional mach_foo

osfmk/foo/foo_main.c            optional mach_foo

osfmk/foo/foo_bar.c             optional mach_foo

osfmk/crud/mandatory_file.c     standard

options MACH_FOO

pseudo-device   mach_foo

pseudo-device   ppp 2

Изменение файлов исходного кода

В ядре OS X автоматически компилируются все файлы исходного кода. Это - ответственность самого файла C, чтобы определить, должно ли его содержание быть включено в сборку или нет.

В примере выше, Вы создали вызванный модуль mach_foo. Предположите, что Вы хотите, чтобы этот файл скомпилировал только на основанных на PowerPC компьютерах. В этом случае необходимо было включать опцию только в MASTER.ppc а не в MASTER.i386. Однако по умолчанию, просто указание файла foo_main.c в files причины это, чтобы быть скомпилированным, независимо от указанных опций компиляции.

Чтобы заставить код скомпилировать только, когда опция mach_foo включена в конфигурацию, необходимо начать каждый исходный файл C со строк

#include <mach_foo.h>

#if (MACH_FOO > 0)

и закончите его

#endif /* MACH_FOO */

Если mach_foo псевдоустройство, и необходимо проверить число mach_foo псевдоустройства включали, можно сделать дальнейшие тесты значения MACH_FOO.

Обратите внимание на то, что файл <mach_foo.h> не что-то, что Вы создаете. Это создается самими make-файлами. Необходимо работать make exporthdrs прежде make all генерировать эти файлы.

Установка флагов отладки в открытом встроенном микропрограммном обеспечении

За исключением паники ядра или вызовов к PE_enter_debugger, не возможно сделать, удаленная отладка ядра, не устанавливая флаги отладки в Открывает Firmware. Эти флаги относятся к обоим gdb и ddb отладка и достаточно важна для гарантирования их собственного раздела.

Для установки этих флагов можно или использовать nvram программа (из командной строки OS X) или доступ Ваш компьютер Открывает Firmware. Можно получить доступ, Открывают Firmware это удержанием Опции O F Команды во время начальной загрузки. Для большинства компьютеров значение по умолчанию для, Открывают Firmware, чтобы представить приглашение командной строки на Вашем мониторе и принять ввод с Вашей клавиатуры. Для некоторых более старых компьютеров необходимо использовать последовательную линию в 38 400, 8N1. (Технически, такие компьютеры не поддерживаются OS X, но некоторые применимы при Дарвине, и таким образом они упоминаются здесь для полноты.)

От Открыть подсказки Firmware можно установить флаги с setenv команда. Из командной строки OS X Вы использовали бы nvram команда. Обратите внимание на то, что при изменении этих флагов необходимо всегда смотреть на старое значение для надлежащего, Открывают переменные Firmware и добавляют debug флаги.

Например, если Вы хотите установить флаги отладки в 0x4, Вы используете одну из следующих команд. Для компьютеров с последними версиями Открывают Firmware, Вы ввели бы

printenv boot-args

setenv boot-args original_contents debug=0x4

от открытого встроенного микропрограммного обеспечения или

nvram boot-args

nvram boot-args="original_contents debug=0x4"

из командной строки (как корень).

Для более старых версий микропрограммного обеспечения интересная переменная boot-command. Таким образом Вы могли бы сделать что-то как

printenv boot-command

setenv boot-command 0 bootr debug=0x4

от открытого встроенного микропрограммного обеспечения или

nvram boot-command

nvram boot-command="0 bootr debug=0x4"

из командной строки (как корень).

Конечно, более важный вопрос - то, какое значение выбрать для отладки отмечает. Таблица 20-1 перечисляет флаги отладки, поддерживающиеся в OS X.

Опция DB_KDP_BP_DIS если Ваши целевые и хост-системы выполняют те же или аналогичные версии OS X с соответствием инструментов разработчика, не доступно во всех системах и не должен быть важным. Последняя опция только доступна в Mac OS 10.2 и позже.

Предотвращение сторожевых проблем таймера

Компьютерам Macintosh разработали различные сторожевые таймеры для защиты системы от определенных типов отказов. Существует два основных сторожевых широко использующиеся таймера: сторожевой таймер управления питанием (не представляют во всех системах), и системный сторожевой таймер катастрофического отказа. Оба сторожевых таймера являются частью аппаратных средств управления питанием.

Первый из них, сторожевого таймера управления питанием, разработан для восстановления системы к известному безопасному состоянию в случае неожиданной потери связи между аппаратными средствами управления питанием и CPU. Этот таймер только присутствует в G4 и более ранних рабочих столах и ноутбуках и в ранних рабочих столах G5. Более в частности это присутствует только в машинах, содержащих PMU (Блок управления питанием) микросхема.

При нормальных обстоятельствах, когда связь с микросхемой PMU будет потеряна, драйвер PMU попытается возвратиться в синхронизации с микросхемой PMU. За возможным исключением мгновенной потери управления клавиатурой и мышью Вы, вероятно, не заметите, что что-либо произошло (и необходимо даже не испытать такой останов, если Вы не пишете драйвер устройства, отключающий прерывания в течение длительного периода времени).

Проблема происходит, когда сбой в коммуникации вызывается путем ввода отладчика, в то время как микросхема PMU находится в одном из этих «небезопасных» состояний. Если микросхему оставят в одном из этих «небезопасных» состояний слишком долго, то это завершит работу компьютера для предотвращения перегрева или других проблем.

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

Для отключения этого сторожевого таймера добавьте параметр pmuflags=1 к загрузочным аргументам ядра. Посмотрите, что Флаги Отладки Установки в Открывают Firmware для получения информации о том, как добавить загрузочный аргумент.

Второй тип сторожевого таймера является системным сторожевым таймером катастрофического отказа. Это обычно только включается в Сервере OS X. Если Ваша целевая машина выполнит Сервер OS X, то Ваша система автоматически перезагрузит в течение секунд после катастрофического отказа для максимизации времени работы сервера. Можно отключить эту автоматическую перезагрузку на функции катастрофического отказа в инструменте администрирования сервера.

Выбор отладчика

Существует две основных среды отладки, поддерживаемые OS X: ddb и gdb. ddb встроенный отладчик, перерабатывающий последовательную линию. В отличие от этого, gdb поддерживается с помощью контейнера отладки, встроенного в ядро, позволяющее удаленному компьютеру в той же физической сети присоединять после паники (или раньше если Вы передаете определенные опции ядру).

Для проблем, включающих расширения сети или низкоуровневую операционную систему bringups, ddb единственный способ сделать отладку. Для других ошибок, gdb обычно проще использовать. Для полноты эта глава описывает, как использовать обоих ddb и gdb сделать основную отладку. С тех пор gdb самостоятельно хорошо документируется и обычно используется для прикладного программирования, эта глава принимает, по крайней мере, передающее знание основ использования gdb и внимание на области, где удаленный (ядро) gdb отличается.

Используя gdb для отладки ядра

gdb, короткий для Отладчика GNU, часть программного обеспечения, обычно используемого для отладки программного обеспечения в системах Linux и UNIX. Этот раздел предполагает, что Вы использовали gdb прежде, и не пытается объяснить основное использование.

В стандартных сборках OS X (и в Ваших сборках, если Вы не компилируете с ddb поддержка), gdb поддержка встроена в систему, но выключена кроме случая паники ядра.

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

Можно заставить тестовый компьютер (целевой объект отладки) заскакивать в отладчик следующими способами:

• отладка на панике

• отладка на NMI

• отладка на начальной загрузке

• программно заскочите в отладчик по умолчанию

  Функция PE_enter_debugger может быть вызван отовсюду в ядре, несмотря на то, что если gdb Ваш отладчик по умолчанию, катастрофический отказ закончится, если сетевое оборудование не будет инициализировано или если gdb не может использоваться в том определенном контексте. Этот вызов описан в заголовке pexpert/pexpert.h.

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

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

Как только Вы создали ядро с помощью узла отладки, необходимо тогда скопировать его в целевой компьютер и перезагрузить целевой компьютер. В этой точке при выполнении отладки только для паники необходимо инициировать панику. Иначе, необходимо сказать целевому компьютеру заскакивать в отладчик путем выпуска NMI (или путем простой начальной загрузки, в случае debug=0x1).

Затем, если Ваше ядро не поддерживает ARP при отладке (и если Вы не включили его с надлежащим флагом отладки), необходимо добавить постоянную запись ARP для цели. Это будет неспособно ответить на запросы ARP при ожидании отладчика. Это гарантирует, что внезапно не исчезнет Ваше соединение. Следующий пример предполагает, что Ваша цель target.foo.com с IP-адресом 10.0.0.69:

$ ping -c 1 target_host_name

ping results: ....

$ arp -an

target.foo.com (10.0.0.69): 00:a0:13:12:65:31

$ sudo arp -s target.foo.com 00:a0:13:12:65:31

$ arp -an

target.foo.com (10.0.0.69) at00:a0:13:12:65:31 permanent

Теперь, можно начать отлаживать путем выполнения следующего:

gdb /path/to/mach_kernel

source /path/to/xnu/osfmk/.gdbinit

p proc0

source /path/to/xnu/osfmk/.gdbinit

target remote-kdp

attach 10.0.0.69

Обратите внимание на то, что ядро Маха передало как параметр gdb должен быть загруженный символом файл ядра, расположенный в BUILD/obj/DEBUG_PPC/mach_kernel.sys (для сборок ядра отладки, RELEASE_PPC для сборок неотладки), не загрузочное ядро, которое Вы скопировали на целевой объект отладки. Иначе большая часть gdb макросы перестанут работать. Корректное ядро должно быть несколько раз более большим, чем нормальное ядро.

Необходимо сделать p proc0 команда и получает .gdbinit файл (из надлежащих источников ядра) дважды для работы вокруг ошибки в gdb. Конечно, если Вам не нужны ни одни из макросов в .gdbinit, можно пропустить те две инструкции. Макросы имеют главным образом интерес для людей, отлаживающих аспекты Маха, хотя они также обеспечивают способы получить информацию о в настоящее время загруженном KEXTs.

При отладке модуля ядра необходимо выполнить некоторую дополнительную работу для получения отладочной информации о модуле. Во-первых, необходимо знать адрес загрузки для модуля. Можно получить эту информацию путем выполнения kextstat (kmodstat в системах рабочий OS X v10.1 или ранее) как корень на цели.

Если Вы уже находитесь в отладчике, то принятие цели не паниковало, необходимо быть в состоянии использовать continue функция в gdb для восстановления цели получите эту информацию, затем инициируйте другой NMI для ронения в отладчик.

Если цель больше не функциональна, и если у Вас есть полностью загруженный символом файл ядра на Вашем узле отладки, соответствующем ядро на Вашем целевом объекте отладки, можно использовать showallkmods макрос для получения этой информации. Получение полностью загруженного символом ядра обычно требует компиляции ядра самостоятельно.

Как только у Вас есть адрес загрузки рассматриваемого модуля, необходимо создать файл символов для модуля. Вы делаете это по-разному на различных версиях OS X.

Для версий 10.1 и ранее, Вы используете kmodsyms программа для создания файла символов для модуля. Если вызывают Ваш KEXT mykext и это загружается в адресе 0xf7a4000, например, Вы изменяете каталоги на mykext.kext/Contents/MacOS и тип:

kmodsyms -k path/to/mach_kernel -o mykext.sym mykext@0xf7a4000

Обязательно укажите корректный путь для ядра Маха, работающего на Вашей цели (предположение, что это не то же как ядро, работающее на Вашем узле отладки).

Для версий после 10.1, у Вас есть две опции. Если Ваш KEXT не разрушает компьютер, когда это загружается, можно спросить kextload генерировать символы во время загрузки путем передачи его следующие опции:

kextload -s symboldir mykext.kext

Это тогда запишет символы для Вашего расширения ядра и его зависимостей в файлы в каталоге, который Вы указали. Конечно, если Ваша цель не отказывает в или вскоре после времени загрузки, это только работает.

Поочередно при отладке существующей паники, или если KEXT не может быть загружен, не вызывая панику, можно генерировать отладочную информацию на узле отладки. Вы делаете это путем ввода:

kextload -n -s symboldir mykext.kext

Если тогда предложит Вам адрес загрузки расширения ядра и адреса всех его зависимостей. Как упомянуто ранее, можно найти адреса с kextstat (или kmodstat) или путем ввода showallkmods внутри gdb.

У Вас должны теперь быть файл или файлы, содержащие символьную информацию это gdb может использовать для определения преобразований адресов в имена в KEXT. Добавить символы от этого KEXT, в gdb на Вашем узле отладки введите команду

add-symbol-file mykext.sym

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

set kdp_read_io=1

set kdp_trans_off=1

(gdb) x/x 0xf8022034

0xf8022034: Cannot access memory at address 0xf8022034

(gdb) set kdp_trans_off=1

(gdb) x/x 0xf8022034

0xf8022034: Cannot access memory at address 0xf8022034

(gdb) set kdp_read_io=1

(gdb) x/x 0xf8022034

0xf8022034: 0x00000020

(gdb)

Используя ddb для отладки ядра

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

• драйверы для встроенного оборудования Ethernet

• обработчики прерываний (аппаратное разнообразие, не потоки обработчика)

• ранняя начальная загрузка перед сетевым оборудованием инициализируется

Когда gdb не практично (или если Вам любопытно), существует второй механизм отладки, который может быть скомпилирован в OS X. Этот механизм вызывают ddb, и подобно kdb отладчик в большей части BSD системы UNIX. Это не совсем столь же просто в использовании как gdb, в основном из-за аппаратных средств должен был использовать его.

В отличие от этого gdb (который использует Ethernet для связи с тупиком ядра), ddb встроен в само ядро и взаимодействует непосредственно с пользователем по последовательной линии. Также в отличие от этого gdb, использование ddb требует создания пользовательского ядра с помощью DEBUG конфигурация. Для получения дополнительной информации о создании этого ядра посмотрите Создание Вашего Первого Ядра.

Если Ваш целевой компьютер имеет два последовательных порта, ddb использует модемный порт (порт SCC 0). Однако, если Ваша цель имеет только один последовательный порт, тот порт, вероятно, присоединен к порту 1 из ячейки SCC, что означает, что необходимо изменить порт по умолчанию, если Вы хотите использовать ddb. Для использования этого порта (порт SCC 1) измените строку:

const int console_unit=0;

в osfmk/ppc/serial_console.c читать:

const int console_unit=1;

и перекомпилируйте ядро.

Как только у Вас есть ядро с ddb поддержка, это относительно просто в использовании. Во-первых, необходимо установить программу эмулятора терминала на узле отладки. Если Ваш узел отладки выполняет Mac OS 9, Вы могли бы использовать ZTerm, например. Для компьютеров OS X, или для компьютерного выполнения Linux или UNIX, minicom обеспечивает хорошую среду. Установка этих программ выходит за рамки этого документа.

Как только Вы загружаете ядро с ddb поддержка, паника позволит Вам заскакивать в отладчик, как будет вызов к PE_enter_debugger. Если DB_KDB флаг не установлен, необходимо будет нажать клавишу D на клавиатуре для использования ddb. Поочередно, если оба DB_KDB и DB_NMI установлены, необходимо быть в состоянии заскочить ddb путем генерации немаскируемого прерывания (NMI). Посмотрите, что Флаги Отладки Установки в Открывают Firmware для получения дополнительной информации о флагах отладки.

Для генерации немаскируемого прерывания удержите команду, опцию, управление и клавиши Shift и поразите Escape (OS X v10.4 и более новый), удержите командную клавишу при нажатии клавиши питания на клавиатуре (на аппаратных средствах с ключом питания) или нажмите кнопку прерывания на целевом компьютере. В этой точке должна зависнуть система, и необходимо видеть ddb вывод на последовательном терминале. Если Вы не делаете, проверьте свою конфигурацию и проверьте указание корректного последовательного порта на обоих компьютерах.

command[/switch] address[,count]