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似乎可以满足我的需要。
I've got a full-heap core dump from a dead process on an x86 Linux machine (kernel 2.6.35-22 if it matters), which I'm attempting to debug in GDB.
Is there a GDB command I can use that means "show me a list of all the memory address regions allocated by this process?" In other words, can I figure out what all the possible valid memory addresses are that I can examine in this dump?
The reason I ask is that I need to search across the entire process heap for a certain binary string, and in order to use the find command, I need to have a start and end address. Simply searching from 0x00 to 0xff.. doesn't work because find halts as soon as it encounters an address it can't access:
(gdb) find /w 0x10000000, 0xff000000,
0x12345678warning: Unable to access target memory at 0x105ef883, halting
search.
So I need to get a list of all the readable address regions in memory so I can search them one at a time.
(The reason I need to do that is I need to find all the structs in memory that point at a certain address.)
None of show mem, show proc, info mem, info proc seem to do what I need.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在 GDB 7.2 中：
您需要
info proc 映射，但在没有/proc时（例如在事后调试期间）它不起作用。请尝试使用
维护信息部分。In GDB 7.2:
You want
info proc mappings, except it doesn't work when there is no/proc(such as during pos-mortem debugging).Try
maintenance info sectionsinstead.如果您有程序和核心文件，则可以执行以下步骤。
1) 在程序上运行 gdb 以及 core 文件
2) 输入 info 文件并查看 core 文件中有哪些不同的段。
示例输出：
在我的例子中，我有 15 个段。每个段都有地址的开始和地址的结束。选择要搜索数据的任何段。例如，让我们选择 load11 并搜索模式。 Load11 的起始地址为 0x08049000，结束地址为 0x804a000。
3) 在段中搜索模式。
如果您没有可执行文件，则需要使用一个程序来打印核心文件所有段的数据。然后您可以在某个地址搜索特定数据。我没有找到任何这样的程序，您可以使用以下链接中的程序来打印核心或可执行文件的所有段的数据。
If you have the program and the core file, you can do the following steps.
1) Run the gdb on the program along with core file
2) type info files and see what different segments are there in the core file.
A sample output:
In my case I have 15 segments. Each segment has start of the address and end of the address. Choose any segment to search data for. For example lets select load11 and search for a pattern. Load11 has start address 0x08049000 and ends at 0x804a000.
3) Search for a pattern in the segment.
If you don't have executable file you need to use a program which prints data of all segments of a core file. Then you can search for a particular data at an address. I don't find any program as such, you can use the program at the following link which prints data of all segments of a core or an executable file.
这是来自上面 phihag 的评论，值得单独回答。这可以工作，但
info proc不适用于 gcc-arm-none-eabi Ubuntu 软件包中的 arm-none-eabi-gdb v7.4.1.20130913-cvs。This is from comment by phihag above, deserves a separate answer. This works but
info procdoes not on the arm-none-eabi-gdb v7.4.1.20130913-cvs from the gcc-arm-none-eabi Ubuntu package.您还可以使用
info files列出进程二进制文件中加载的所有二进制文件的所有部分。You can also use
info filesto list all the sections of all the binaries loaded in process binary.我刚刚看到以下内容：
此处
它可能允许您进行搜索而无需考虑内存是否可访问。
I have just seen the following:
here
It might allow you to search without regard if the memory is accessible.
请注意，如果您想确定进程的共享内存段、mmap() 区域等映射到其地址空间的位置，那么这些都不会帮助您。
此信息似乎不包含在核心中。
maintenance info target-sections和maintenance info target都没有显示它。（所以它可能根本不存在，或者充其量是在 gdb 不使用的核心部分中。也许可以从内部 libc 簿记状态中找出一些信息，但不是以通用方式）。
Note that none of these will help you if you want to identify where the process had shared-memory segments,
mmap()ed regions, etc mapped into its address space.This info doesn't seem to be included in the core. Neither
maintenance info target-sectionsnormaintenance info targetshow it.(So it probably just doesn't exist, or at best is in a core section gdb doesn't use. It might be possible to figure some out from internal libc book-keeping state, but not in a generic way).
维护信息节的问题是该命令尝试从二进制文件的节头中提取信息。如果二进制文件被触发（例如通过
sstrip），或者当加载程序在加载后可能更改内存权限时给出错误信息（例如RELRO的情况），则它不起作用。The problem with
maintenance info sectionsis that command tries to extract information from the section header of the binary. It does not work if the binary is tripped (e.g bysstrip) or it gives wrong information when the loader may change the memory permission after loading (e.g. the case ofRELRO).