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

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/5691193/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-04 00:43:35  来源:igfitidea点击:

GDB: Listing all mapped memory regions for a crashed process

clinuxgdb

提问by Crashworks

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.

我从 x86 Linux 机器(内核 2.6.35-22,如果重要的话)上的死进程获得了一个完整的堆核心转储,我正试图在 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?

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

The reason I ask is that I need to search across the entire process heapfor a certain binary string, and in order to use the findcommand, I need to have a start and end address. Simply searching from 0x00 to 0xff.. doesn't work because findhalts as soon as it encounters an address it can't access:

我问的原因是我需要在整个进程堆中搜索某个二进制字符串,并且为了使用该find命令,我需要有一个开始和结束地址。简单地从 0x00 搜索到 0xff .. 不起作用,因为find一旦遇到无法访问的地址就会停止:

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

warning: Unable to access target memory at 0x105ef883, halting search.

(gdb) 查找 /w 0x10000000, 0xff000000, 0x12345678

警告:无法访问 0x105ef883 处的目标内存,停止搜索。

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 thatis I need to find all the structs in memory that point ata certain address.)

(我需要做的原因是,我需要找到所有的结构在内存里某个地址。)

None of show mem, show proc, info mem, info procseem to do what I need.

没有show memshow procinfo meminfo proc似乎做什么,我需要。

采纳答案by Employed Russian

In GDB 7.2:

在 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.

You want info proc mappings, except it doesn't work when there is no /proc(such as during pos-mortem debugging).

你想要info proc mappings,除非它在没有时不起作用/proc(例如在验尸调试期间)。

Try maintenance info sectionsinstead.

试试吧maintenance info sections

回答by tothphu

I have just seen the following:

我刚刚看到以下内容:

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

here

这里

It might allow you to search without regard if the memory is accessible.

它可能允许您在不考虑内存是否可访问的情况下进行搜索。

回答by tothphu

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

1) 在程序上运行 gdb 和核心文件

 $gdb ./test core

2) type info files and see what different segments are there in the core file.

2)输入信息文件并查看核心文件中有哪些不同的段。

    (gdb)info files

A sample output:

示例输出:

    (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

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.

就我而言,我有 15 个段。每个段都有地址的开始和地址的结束。选择要搜索数据的任何细分。例如,让我们选择 load11 并搜索一个模式。Load11 的起始地址为 0x08049000,结束于 0x804a000。

3) Search for a pattern in the segment.

3) 在段中搜索模式。

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

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.

如果您没有可执行文件,则需要使用一个程序来打印核心文件所有段的数据。然后您可以在某个地址搜索特定数据。我没有找到任何程序,您可以在以下链接中使用该程序,该程序打印核心或可执行文件的所有段的数据。

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

回答by alexei

(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

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.

这是来自 phihag 上面的评论,值得单独回答。这有效,但info proc不适用于来自 gcc-arm-none-eabi Ubuntu 软件包的 arm-none-eabi-gdb v7.4.1.20130913-cvs。

回答by abhi

You can also use info filesto list all the sections of all the binaries loaded in process binary.

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

回答by Ta Thanh Dinh

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 by sstrip) or it gives wrong information when the loader may change the memory permission after loading (e.g. the case of RELRO).

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