GDB：列出崩溃进程的所有映射内存区域-IT科技

GDB：列出崩溃进程的所有映射内存区域

2024-11-05 08:37:00

admin

原创

245

摘要：问题描述：我从 x86 Linux 机器（如果重要的话，内核是 2.6.35-22）上的一个死进程获得了一个全堆核心转储，我正尝试在 GDB 中对其进行调试。是否有一个 GDB 命令可用于“显示此进程分配的所有内存地址区域的列表？”换句话说，我能否找出在此转储中可以检查的所有可能的有效内存地址？我之所以问这个...

问题描述：

我从 x86 Linux 机器（如果重要的话，内核是 2.6.35-22）上的一个死进程获得了一个全堆核心转储，我正尝试在 GDB 中对其进行调试。

是否有一个 GDB 命令可用于“显示此进程分配的所有内存地址区域的列表？”换句话说，我能否找出在此转储中可以检查的所有可能的有效内存地址？

我之所以问这个问题，是因为我需要在整个进程堆中搜索某个二进制字符串，并且为了使用该find命令，我需要有一个起始地址和结束地址。简单地从 0x00 到 0xff 搜索是行不通的，因为find一旦遇到无法访问的地址就会停止：

（gdb）查找/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 &quot;/home/emntech/debugging/test&quot;.
    Local core dump file:
`/home/emntech/debugging/core&#039;, 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：

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

这是来自上面 phihag 的评论，值得单独回答。这有效，但info proc在 gcc-arm-none-eabi Ubuntu 包中的 arm-none-eabi-gdb v7.4.1.20130913-cvs 上无效。

解决方案 4：

您还可以使用它info files来列出进程二进制文件中加载的所有二进制文件的所有部分。

解决方案 5：

我刚刚看到以下内容：

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

这里

它可能允许您进行搜索而不考虑内存是否可访问。

解决方案 6：

mmap()请注意，如果您想确定进程的共享内存段、 ed 区域等映射到其地址空间的位置，这些都无济于事。

此信息似乎未包含在核心中。既不包含maintenance info target-sections也不maintenance info target显示。

（所以它可能不存在，或者充其量存在于 gdb 不使用的核心部分。可能可以从内部 libc 簿记状态中找出一些答案，但不是以通用的方式）。

解决方案 7：

的问题在于maintenance info sections该命令试图从二进制文件的节头中提取信息。如果二进制文件被触发（例如），则该命令不起作用sstrip，或者当加载程序在加载后可能更改内存权限时（例如的情况），该命令会给出错误的信息RELRO。