Удаленный посмертный анализ coredump без точных символов отладки для общих системных библиотек - PullRequest
7 голосов
/ 02 декабря 2010

Как вы обычно обходите эту проблему?Представьте себе, что поток падает в коде libc (который является системной общей библиотекой) на компьютере1, а затем генерирует coredump.Но компьютер2, на котором будет анализироваться этот coredump, может иметь другую версию libc.

Итак:

  1. Насколько важно иметь одну и ту же общую библиотеку на удаленном компьютере?Будет ли GDB корректно восстанавливать стек трассировки, не имея точно такой же версии libc на Conputer2?

  2. Насколько важно иметь правильные символы отладки для libc?Будет ли GDB правильно восстанавливать стековую трассировку, не имея одинаковых отладочных символов на компьютере2?

  3. И каков «правильный» способ избежать этой проблемы несовпадения символов отладки для общих системных библиотек?Мне кажется, что нет единого решения, которое решает эту проблему элегантным способом?Может кто-нибудь может поделиться своим опытом?

1 Ответ

13 голосов
/ 03 декабря 2010
  1. Это зависит. На некоторых процессорах, таких как x86_64, корректные дескрипторы разматывания необходимы для правильной размотки стека GDB. На такой машине анализ coredump с использованием несоответствующего libc, скорее всего, даст полный мусор.

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

  3. Суть вашего вопроса неверна - символы отладки не имеют к этому никакого отношения. «Правильный» способ анализа coredump на C2, когда этот coredump был создан на C1, состоит в том, чтобы иметь копию библиотек C1 (например, /tmp/C1/lib/...) и дать указание GDB использовать эту копию вместо установленной C2 libc с

    (gdb) set solib-absolute-prefix /tmp/C1

команда.

Примечание : приведенное выше значение должно быть активным до загрузки ядра в GDB. Это:

gdb exe core
(gdb) set solib-absolute-prefix /tmp/C1

не будет работать (ядро считывается до того, как настройка вступит в силу).

Вот правильный путь:

gdb exe
(gdb) set solib-absolute-prefix /tmp/C1
(gdb) core core

(я пытался найти ссылку на это в Интернете, но не нашел).

Что такое раскручиваемые дескрипторы?

Дескрипторы размотки требуются, когда код компилируется без указателей кадра (по умолчанию для x86_64 в оптимизированном режиме). Такой код не сохраняет регистр% rbp, и поэтому GDB нужно сказать, как «сделать шаг назад» от текущего кадра к кадру вызывающей стороны (этот процесс также известен как разматывание стека).

Почему libc.so C1 не включен в ядро?

Основной файл обычно содержит только содержимое записываемых сегментов адресного пространства программы. Сегменты, доступные только для чтения (где находятся исполняемый код и дескрипторы размотки), обычно не нужны - вы можете просто прочитать их непосредственно из libc.so на диске.

За исключением того, что это не работает, когда вы анализируете ядро ​​C1 на C2!

Некоторые (но не все) операционные системы позволяют настраивать «fulldudumps», где ОС будет также выводить сопоставления только для чтения, чтобы вы могли анализировать ядро ​​на любой машине.

...