Формат файла ELF

Короткая копия через источник GDB, где я могу найти документацию о формате, используемом для создания файлов ядра?

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

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

Теперь "readelf -a core" сообщает мне, что почти все сегменты в основном файле имеют тип "load" - я бы предположил, что это сегменты .text и .bss/.data от всех участвующих файлов, а также сегмент стека. Запрещая эти сегменты нагрузки, есть один сегмент примечаний, но, похоже, он не содержит карту. Итак, как информация о том, какой файл соответствует сегменту, хранится в основном файле? Разделяются ли эти сегменты "загрузки" определенным образом, чтобы включить информацию о файле?

Ответы

Ответ 1

Не так много gdb как библиотека bfd, используемая gdb, binutils и т.д.

Ответ 2

Формат файла дампа основной памяти использует формат ELF, но не описан в стандарте ELF. AFAIK, нет авторитетной ссылки на это.

Так как же информация о том, какому файлу соответствует сегмент, хранится в основном файле?

Много дополнительной информации содержится в примечаниях ELF. Вы можете использовать readelf -n, чтобы увидеть их.

Примечание CORE/NT_FILE определяет связь между диапазоном адресов памяти и файлом (+ смещение):

Page size: 1
             Start                 End         Page Offset
0x0000000000400000  0x000000000049d000  0x0000000000000000
    /usr/bin/xchat
0x000000000069c000  0x00000000006a0000  0x000000000009c000
    /usr/bin/xchat
0x00007f2490885000  0x00007f24908a1000  0x0000000000000000
    /usr/share/icons/gnome/icon-theme.cache
0x00007f24908a1000  0x00007f24908bd000  0x0000000000000000
    /usr/share/icons/gnome/icon-theme.cache
0x00007f24908bd000  0x00007f2490eb0000  0x0000000000000000
    /usr/share/fonts/opentype/ipafont-gothic/ipag.ttf
[...]

Для каждого потока у вас должна быть заметка CORE/NT_PRSTATUS, в которой вы найдете регистры потока (включая указатель стека). Из этого вы можете определить положение стеков.

Дополнительная информация о формате основных файлов ELF:

Анатомия основного файла ELF (отказ от ответственности: я написал этот)
Краткий обзор основных дампов

Ответ 3

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

Ответ 4

Дополнительная информация о процессе, сгенерированном основным файлом, сохраняется в разделе примечаний ELF, хотя и в конкретной операционной системе. Например, см. справочную страницу ядра (5) для NetBSD.

Ответ 5

Более простым решением вашей проблемы может быть анализ текста из /proc/ $pid/maps, чтобы определить, к какому файлу относится данный виртуальный адрес. Затем вы можете проанализировать соответствующий файл.

Kenshoto open source VDB (отладчик) использует этот подход, если вы можете читать python, это хороший пример.