Может ли GDB декодировать ядро, если бы оно было piped?

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

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

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

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

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

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

Непосредственная проблема с использованием squashfsв core_patternзаключается в том, что нет очевидного способа вызвать mksquashfsна стандартном вводе.Возможно, самый простой способ обойти это — позволить базовому файлу существовать в несжатой форме достаточно долго, чтобы вызвать mksquashfs. Более экономичный подход может включать в себя написание кода, который может генерировать формат squashfsиз стандартного ввода; это, вероятно, будет простым, если mksquashfsникогда не будет искать назад в файле, который он включает в изображение squashfs(Я не знаю этого наверняка, но мое понимание формата squashfsпредполагает, что это по крайней мере возможность ).

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

Обработчик дампа памяти ядра может генерировать обратную трассировку процесса-зомби без предварительной записи дампа памяти на диск.

Я предположил, что ABRT может это сделать. Однако патч вроде есть, но его еще не слили:

• https://github.com/abrt/abrt/issues/872