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

Question

Я получил дамп ядра полной кучи из мертвого процесса на компьютере с Linux x86 (ядро 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, кажется, не делает то, что мне нужно.

Answer 1

В ГБД 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 вместо.

Answer 2

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

1) Запустить GDB в программе вместе с файлом типа core

 $gdb ./test core

2)info-файлы и посмотрите, какие разные сегменты есть в основном файле.

    (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

Answer 3

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

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

здесь

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

Answer 4

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

Answer 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 не работает на arm-none-eabi-gdb v7.4.1.20130913-cvs из пакета Ubuntu gcc-arm-none-eabi.

Answer 6

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