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

У меня есть огромные файлы core , и, следовательно, установите, что core_pattern установлен в gzip поскольку они написаны.

Позже, если обратная трассировка должна быть получена, сначала нужно сделать gunzip (и это займет очень много времени!), Прежде чем файл core будет загружен в gdb .

Я хотел знать, есть ли способ связать core (как он создается) с gdb (или любой другой программой, которая может извлекать backtrace ). Я проверил gdb , и, похоже, такого выбора нет (он readelf не readelf ); прежде чем я смог взломать что-то подобное, я хотел знать, есть ли что-нибудь с форматом core ELF (на x86_64 , GNU / Linux), который может помешать этому работать?

— РЕДАКТИРОВАТЬ —

grok'd через источники readelf и другие программы, которые могут генерировать backtrace, и они, кажется, seek() через файл вперед и назад ! Я не уверен, что это абсолютно необходимо, или если его можно читать и собирать всю необходимую информацию за один проход (так как я хочу читать из трубы, поиск не является вариантом!)

  • есть ли способ узнать, присутствуют ли сигналы в вашем приложении и какие сигналы есть?
  • Регистрируются ли регистры FPU / SSE / AVX в исходных дампах?
  • gdb не входит в функцию, хотя доступен источник
  • Вопрос о подключении gdb (ptrace_scope доступен только для чтения)
  • Переключение между общими буферами в режиме emacs gdb без мыши (в текстовом терминале)
  • Стрелка вверх GDB не работает
  • Аппаратная точка останова в GDB + QEMU отсутствует start_kernel
  • Как отладить сбой семпла?
  • 2 Solutions collect form web for “Может ли GDB декодировать ядро, если он был передан по трубопроводу?”

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

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

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

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

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

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

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

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

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

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

    Linux и Unix - лучшая ОС в мире.