Выполняется ли дамп ядра сам по себе?
На странице Википедии о дампе ядра написано
В Unix-подобных системах дампы ядра обычно используют стандартный исполняемый формат изображения:
a.out in older versions of Unix, ELF in modern Linux, System V, Solaris, and BSD systems, Mach-O in OS X, etc.
Означает ли это, что дамп ядра является исполняемым сам по себе? Если нет, то почему нет?
Редактировать: Поскольку @WumpusQ. Уамбли упоминает coredump_filter в комментарии, возможно, вышеупомянутый вопрос должен быть: можно ли создать дамп ядра так, чтобы он выполнялся сам по себе?
4 ответа
В более старых вариантах Unix по умолчанию в текстовый дамп включался текст, а также данные, но он также предоставлялся в формате a.out, а не в формате ELF. Сегодняшнее поведение по умолчанию (в Linux, конечно, на 100% нет уверенности в вариантах BSD, Solaris и т. Д.) - иметь дамп ядра в формате ELF без текстовых разделов, но это поведение можно изменить.
Тем не менее, дамп ядра не может быть выполнен напрямую без какой-либо помощи. Причина в том, что в простом файле ядра отсутствуют две вещи. Один из них - точка входа, другой - код для восстановления состояния ЦП в состояние в момент или непосредственно перед тем, как произошел дамп (по умолчанию также отсутствуют текстовые разделы).
В AIX была утилита undump, но я понятия не имею, что с ней произошло. Его нет ни в одном стандартном дистрибутиве Linux, о котором я знаю. Как упомянуто выше (@WumpusQ), также есть попытка подобного проекта для Linux, упомянутого в комментариях выше, однако этот проект не завершен и не восстанавливает состояние процессора в исходное состояние. Это, однако, все еще достаточно хорошо в некоторых конкретных случаях отладки.
Также стоит упомянуть, что существуют другие файлы в формате ELF, которые также не могут быть выполнены, но не являются основными файлами. Например, объектные файлы (выходные данные компилятора) и файлы.so (общие объекты). Для разрешения внешних адресов требуется этап связывания перед запуском.
Я написал на этот вопрос создателю undump утилита для его экспертизы, и получил следующий ответ:
Как уже упоминалось в некоторых ответах, можно включить разделы кода, установив coredump_filter, но это не по умолчанию для Linux (и я не совсем уверен в вариантах BSD и Solaris). Если различные разделы кода сохранены в исходном дампе ядра, на самом деле ничего не пропало для создания нового исполняемого файла. Однако для этого требуются некоторые изменения в исходном файле ядра (например, включение точки входа и указание этой точки входа на код, который будет восстанавливать регистры ЦП). Если основной файл будет изменен таким образом, он станет исполняемым файлом, и вы сможете его запустить. К сожалению, некоторые состояния не будут сохранены, поэтому новый исполняемый файл не сможет работать напрямую. Открытые файлы, сокеты, пипсы и т. Д. Не будут открыты и могут даже указывать на другие FD (которые могут вызывать всякие странные вещи). Однако, скорее всего, этого будет достаточно для большинства задач отладки, таких как запуск небольших функций из gdb (так что вы не получите "не запускаемый исполняемый" материал).
Существует два типа дампов ядра: дампы ядра системы и дампы ядра процесса. Они отличаются во многих аспектах, таких как способ их создания и метод, используемый для их анализа.
В большинстве случаев сигнал, приводящий к сбою приложения, - это SIGSEGV (нарушение сегментации) или SIGBUS.
Подобные виды сигналов запускают дамп ядра.. может быть, вызовем его..
Как говорили другие парни, я не думаю, что вы можете выполнить файл дампа ядра без исходного двоичного файла.
Если вы заинтересованы в отладке двоичного файла (и в него включены отладочные символы, другими словами, он не удален), вы можете запустить gdb binary core,
Внутри GDB вы можете использовать bt команда (backtrace) для получения трассировки стека при сбое приложения.