GDB: список всех областей отображаемой памяти для разбитого процесса

У меня есть дамп ядра с полным куче от мертвого процесса на машине x86 Linux (ядро 2.6.35-22, если это имеет значение), который я пытаюсь отладить в GDB.

Есть ли команда GDB, которую я могу использовать, это означает: "Покажите мне список всех областей адресов памяти, выделенных этим процессом?" Другими словами, могу ли я выяснить, какие все возможные допустимые адреса памяти я могу проверить на этом дампе?

Причина, по которой я спрашиваю, заключается в том, что мне нужно искать всю кучу процесса для определенной двоичной строки, а для использования команды find мне нужен начальный и конечный адрес. Просто поиск от 0x00 до 0xff.. не работает, потому что find останавливается, как только он встречает адрес, к которому он не может получить доступ:

(gdb) find/w 0x10000000, 0xff000000, 0x12345678

предупреждение: невозможно получить доступ к целевой памяти на 0x105ef883, остановив поиск.

Поэтому мне нужно получить список всех областей читаемого адреса в памяти, чтобы я мог их искать по одному.

(Причина, по которой мне нужно это сделать: мне нужно найти все структуры в памяти, которые указывают на определенный адрес.)

Ни один из show mem, show proc, info mem, info proc, похоже, делает то, что мне нужно.

Ответ 1

В GDB 7.2:

(gdb) help info proc
Show /proc process information about any running process.
Specify any process id, or use the program being debugged by default.
Specify any of the following keywords for detailed info:
  mappings -- list of mapped memory regions.
  stat     -- list a bunch of random process info.
  status   -- list a different bunch of random process info.
  all      -- list all available /proc info.

Вы хотите info proc mappings, за исключением того, что он не работает, когда нет /proc (например, при отладке поломки).

Попробуйте maintenance info sections.

Ответ 2

Если у вас есть программа и основной файл, вы можете сделать следующие шаги.

1) Запустите gdb в программе вместе с файлом ядра

 $gdb ./test core

2) введите информацию о файлах и посмотрите, какие разные сегменты находятся в основном файле.

    (gdb)info files

Пример вывода:

    (gdb)info files 

    Symbols from "/home/emntech/debugging/test".
    Local core dump file:
`/home/emntech/debugging/core', file type elf32-i386.
  0x0055f000 - 0x0055f000 is load1
  0x0057b000 - 0x0057c000 is load2
  0x0057c000 - 0x0057d000 is load3
  0x00746000 - 0x00747000 is load4
  0x00c86000 - 0x00c86000 is load5
  0x00de0000 - 0x00de0000 is load6
  0x00de1000 - 0x00de3000 is load7
  0x00de3000 - 0x00de4000 is load8
  0x00de4000 - 0x00de7000 is load9
  0x08048000 - 0x08048000 is load10
  0x08049000 - 0x0804a000 is load11
  0x0804a000 - 0x0804b000 is load12
  0xb77b9000 - 0xb77ba000 is load13
  0xb77cc000 - 0xb77ce000 is load14
  0xbf91d000 - 0xbf93f000 is load15

В моем случае у меня 15 сегментов. Каждый сегмент имеет начало адреса и конца адреса. Выберите любой сегмент для поиска данных. Например, вы можете выбрать load11 и искать шаблон. Load11 имеет начальный адрес 0x08049000 и заканчивается на 0x804a000.

3) Найдите шаблон в сегменте.

(gdb) find /w 0x08049000 0x0804a000 0x8048034
 0x804903c
 0x8049040
 2 patterns found

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

 http://emntech.com/programs/printseg.c

Ответ 3

Я только что видел следующее:

set mem inaccessible-by-default [on|off]

здесь

Это может позволить вам искать, независимо от того, доступна ли память.

Ответ 4

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

Ответ 5

(gdb) maintenance info sections 
Exec file:
    `/path/to/app.out', file type elf32-littlearm.
    0x0000->0x0360 at 0x00008000: .intvecs ALLOC LOAD READONLY DATA HAS_CONTENTS

Это комментарий от phihag выше, заслуживает отдельного ответа. Это работает, но info proc не находится на руке-none-eabi-gdb v7.4.1.20130913-cvs из пакета Ubuntu gcc-arm-none-eabi.

Ответ 6

Проблема с maintenance info sections заключается в том, что команда пытается извлечь информацию из заголовка раздела двоичного файла. Он не работает, если двоичный код отключен (например, sstrip) или он дает неверную информацию, когда загрузчик может изменить разрешение памяти после загрузки (например, в случае RELRO).