возможно ли отображать отладочные символы KEXT в журнале паники по умолчанию?

Возвращаясь к ходу вещей с IOKit (изменения USB, которые произошли с El Capitan, казались довольно широкими), я обнаружил, что отладка журналов паники kext - это боль в задней части.

Пока я разрабатываю и тестирую, можно ли оставить символы IN в расширении ядра, чтобы они распечатывались в трассировке panic.log?

Для моего отладочного KEXT я попытался изменить как параметр «Удалить символы отладки во время копирования» (также известный как COPY_PHASE_STRIP), так и целевые настройки «Удалить связанный продукт» (также известный как STRIP_INSTALLED_PRODUCT) на NO.

Я все еще получаю несимволизированный вывод в своих журналах паники. Мне просто не повезло, что MacOS просто не делает этого, или есть еще одна настройка, которую я упускаю?

т.е. вместо:

Anonymous UUID:       A8A49864-0847-0BFD-AE70-67EE1BA71682

Fri Dec 18 07:43:19 2015

*** Panic Report ***
panic(cpu 3 caller 0xffffff8013d98fd9): Kernel trap at 0xffffff7f96f00056, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000018, CR3: 0x000000022c105000, CR4: 0x0000000000002660
RAX: 0x00000000c0a8bc01, RBX: 0x0000000000000000, RCX: 0x0000000000000000, RDX: 0x0000000000003dbd
RSP: 0xffffff811dd2b810, RBP: 0xffffff811dd2b8a0, RSI: 0x0000000027a3aee5, RDI: 0x00000000c0a8bc01
R8:  0x0000000000000000, R9:  0x0000000000000000, R10: 0x0000000000000000, R11: 0x0000000000000000
R12: 0xffffff811799b400, R13: 0xffffff8025bb6530, R14: 0x000000000000012c, R15: 0xffffff802a051980
RFL: 0x0000000000010296, RIP: 0xffffff7f96f00056, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000000000018, Error code: 0x0000000000000000, Fault CPU: 0x3, PL: 0

Backtrace (CPU 3), Frame : Return Address
0xffffff811dd2b4a0 : 0xffffff8013c838c7 
0xffffff811dd2b520 : 0xffffff8013d98fd9 
0xffffff811dd2b700 : 0xffffff8013db7d83 
0xffffff811dd2b720 : 0xffffff7f96f00056 
0xffffff811dd2b8a0 : 0xffffff7f96f00571 
0xffffff811dd2b9a0 : 0xffffff7f96f01490 
0xffffff811dd2ba50 : 0xffffff7f96efaf85 
0xffffff811dd2bab0 : 0xffffff7f94f8ea66 
0xffffff811dd2baf0 : 0xffffff7f94f8e795 
0xffffff811dd2bb50 : 0xffffff7f94f8e9c8 
0xffffff811dd2bb90 : 0xffffff8013f2da05 
0xffffff811dd2bcc0 : 0xffffff8013f16a0e 
0xffffff811dd2bd50 : 0xffffff8013ef5ed0 
0xffffff811dd2bdd0 : 0xffffff8013eeab70 
0xffffff811dd2be50 : 0xffffff801419b207 
0xffffff811dd2bef0 : 0xffffff801419b03e 
0xffffff811dd2bf50 : 0xffffff80141fcf9f 
0xffffff811dd2bfb0 : 0xffffff8013db8586 

Я хотел бы увидеть:

Anonymous UUID:       A8A49864-0847-0BFD-AE70-67EE1BA71682

Fri Dec 18 07:43:19 2015

*** Panic Report ***
panic(cpu 3 caller 0xffffff8013d98fd9): Kernel trap at 0xffffff7f96f00056, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000018, CR3: 0x000000022c105000, CR4: 0x0000000000002660
Fault CR2: 0x0000000000000018, Error code: 0x0000000000000000, Fault CPU: 0x3, PL: 0

Backtrace (CPU 3), Frame : Return Address
MyWorkOfArtKext::doSomething : 0xffffff8013c838c7 
MyWorkOfArtKext::start : 0xffffff8013d98fd9 

person Michael Dautermann    schedule 18.12.2015    source источник


Ответы (1)


Предполагая, что вы явно не удаляете символы, они останутся в вашем двоичном файле kext. Проблема в том, что динамический загрузчик ядра не сохраняет их в памяти. Однако вы можете изменить это, установив аргумент ядра keepsyms=1 (либо через переменную nvram boot-args, либо через com.apple.Boot.plist в /Library/Preferences/SystemConfiguration/) — если вы установите этот флаг, ядро ​​​​сохранит символы для кекстов и самого ядра, а также символизирует трассировку стека в панике. журналы.

Обратите внимание, что вы по-прежнему будете получать имена символов в стиле C, поэтому вам нужно будет расшифровать любые имена функций C++ с помощью команды c++filt.

Обновление: keepsyms=1, похоже, не соблюдается для ядер Apple Silicon/arm64e, к сожалению.

person pmdj    schedule 18.12.2015
comment
Мне потребовалось пару дней, чтобы вернуться к своему kext, и ваше решение отлично работает. Было бы неплохо, если бы в журналах паники были номера строк, но, по крайней мере, символы помогают нагляднее. Жаль, что мало людей хотят работать над кекстами, иначе у вас уже был бы золотой значок. Еще раз спасибо и счастливых вам праздников. - person Michael Dautermann; 21.12.2015
comment
Пожалуйста! Я делаю это не ради золотых значков, хотя, думаю, один из них был бы неплох. :-) - person pmdj; 21.12.2015
comment
Номера строк потребуют возможности анализировать полные данные DWARF в ядре, а не только таблицу символов, так что я думаю, что это, вероятно, будет слишком сложно сделать внутри самого ядра, тем более, что вам также придется загружать любые файлы . dSYM в память во время загрузки kext, что также потребует гораздо больше оперативной памяти. Инструмент командной строки atos может вычислить для вас номера строк, или в реальной ситуации, когда произошел сбой, вам, вероятно, лучше всего использовать lldb для отладки ядра через Ethernet или FireWire, что даст вам больше, чем просто номера строк. - person pmdj; 21.12.2015