核心转储注释部分 [英] Core dump note section
问题描述
继我的手动生成核心转储文件的问题后,我决定跳水我能够构建基本的核心转储结构,并将我的死程序的内存返回到大型LOAD部分的核心转储中。在GDB中调试时,我的变量回来了,没有问题。
这里有棘手的部分,我该如何让GDB检索程序在崩溃时的位置信息。
我知道,核心转储包含这些信息(cpu寄存器等)。这是一个 objdump -h 给出的真正的核心转储:
core.28339 :文件格式elf32-i386
部分:
Idx名称大小VMA LMA文件关闭Algn
0 note0 000001e8 00000000 00000000 000000f4 2 ** 0
CONTENTS,READONLY
1 .reg / 28339 00000044 00000000 00000000 00000150 2 ** 2
目录
2 .reg 00000044 00000000 00000000 00000150 2 ** 2
目录
3 .auxv 000000a0 00000000 00000000 0000023c 2 ** 2
目录
4 load1a 00001000 08010000 00000000 00001000 2 ** 12
目录,ALLOC,LOAD,READONLY,CODE
..其他负载部分...
我发现感谢 readelf 这些.reg部分包含映射的数据从一些结构:
注释在偏移量0x000000f4与长度0x000001 e8:
所有者数据大小描述
核心0x00000090 NT_PRSTATUS(prstatus结构)
核心0x0000007c NT_PRPSINFO(prpsinfo结构)
核心0x000000a0 NT_AUXV(辅助向量)
有人可以给我关于如何构建Notes部分的指导吗?
我试图直接将这些结构写入我的文件,它没有工作,我显然在这里错过了一些东西。
我查看了 Google Coredumper代码,并将其中的一些内容,但编写注释部分并不那么简单,并且欢迎任何有关其内容及其格式的详细信息。
编辑#1:关注第1条评论
我发现我的Elf文件应该如下构造: 然后,我将不得不放置3条记录,一条用于 prstatus ,一条用于 prpsinfo 和一个用于辅助矢量。 这似乎是正确的方式,因为 readelf 给了我类似输出为真正的核心转储结果。 编辑#2:得到正确的结构后 我现在正在努力处理组成笔记记录的不同结构。 这是我运行eu-readelf时得到的结果 - 注释在我的核心转储: 这是我在真正的核心转储上运行相同命令时得到的结果: 有人有没有关于为什么我的笔记记录没有正确读取的线索或解释? 谢谢!
偏移量为0x74的540字节的注释段:
所有者数据大小类型
核心336 PRSTATUS
核心136 PRPSINFO
核心8 AUXV
空白
Note段在偏移量0xf4处为488字节:
所有者数据大小类型
核心数量144 PRSTATUS
info.si_signo:11,info.si_code: 0,info.si_errno:0,cursig:11
sigpend:<>
sighold:<>
pid:28339,ppid:41446,pgrp:28339,sid:41446
utime:0.000000,stime:0.000000,cutime:0.000000,cstime:0.000000
orig_eax:-1,fpvalid:0
ebx:-1 ecx:0 edx:0
esi:0 edi:0 ebp:0xffb9fcbc
eax:-1 eip:0x08014b26 eflags:0x00010286
esp:0xffb9fcb4
ds:0x002b es:0x002b fs:0x0000 gs:0x0000 cs:0x0023 ss:0x002b
CORE 124 PRPSINFO
state:0,sname:R,zomb:0,nice:0,flag:0x00400400
uid:9432,gid:6246,pid:28339,ppid:41446,pgrp:28339,sid:41446
fname:pikeos_app,psargs:./pikeos_app
核心160 AUXV
SYSINFO:0xf7768420
SYSINFO_EHDR:0xf7768000
HWCAP:0xbfebfbff< fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe>
PAGESZ:4096
CLKTCK:100
PHDR:0x8010034
PHENT:32
PHNUM:2
基准:0
标志:0
ENTRY:0x80100be
UID:9432
EUID:9432
GID:6246
EGID:6246
安全:0
RANDOM:0xffb9ffab
EXECFN:0xffba1feb
PLATFORM:0xffb9ffbb
NULL
我认为这可能是由于不正确的偏移量造成的,但为什么记录要正确列出?
<解决方案
前段时间,我的CRIU图像转换为核心转储项目时遇到了同样的麻烦。它完全用Python编写(甚至精灵结构都在ctypes中),所以它可以作为指导。请参阅 https://github.com/efiop/criu-coredump .I.e。一切的结构可以在这里看到 https://github.com /efiop/criu-coredump/blob/master/criu_coredump/core_dump.py 。
Following my question about manually generating a core dump file, I decided to dive into it and get my hands dirty.
I am able to build the basic core dump structure and get my dead program's memory back into the core dump within a big LOAD section. When debugging in GDB, my variables are back, no problem with that. Here comes the tricky part, how do I get GDB to retrieve information about where the program was when it crashed.
I know that the note section of the core dump contains this information (cpu registers among others). Here is what a objdump -h gives for a "real" core dump :
core.28339: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 note0 000001e8 00000000 00000000 000000f4 2**0
CONTENTS, READONLY
1 .reg/28339 00000044 00000000 00000000 00000150 2**2
CONTENTS
2 .reg 00000044 00000000 00000000 00000150 2**2
CONTENTS
3 .auxv 000000a0 00000000 00000000 0000023c 2**2
CONTENTS
4 load1a 00001000 08010000 00000000 00001000 2**12
CONTENTS, ALLOC, LOAD, READONLY, CODE
.. other load sections ...
I figured out thanks to readelf that those .reg sections contain data mapped from some structures :
Notes at offset 0x000000f4 with length 0x000001e8:
Owner Data size Description
CORE 0x00000090 NT_PRSTATUS (prstatus structure)
CORE 0x0000007c NT_PRPSINFO (prpsinfo structure)
CORE 0x000000a0 NT_AUXV (auxiliary vector)
Can someone give me directions on how is structured the Notes section ? I tried writing directly those structures to my file, it did not work and I am obviously missing something here. I looked at the Google Coredumper code and took some bits of it, but writing the note section is not that simple and any detailed information about what it exactly contains and its format are welcomed.
Edit #1 : following 1st comment
I figured out my Elf file should be structured as follows :
- Elf header ElfW(Ehdr)
- Program headers (Ehdr.e_phnum times ElfW(Phdr)), here i basically used one PT_NOTE and one PT_LOAD headers
- Note sections :
- Section's header (ElfW(Nhdr))
- Section's name (.n_namesz long)
- Section's data (.n_descsz long)
- Program section containing all my program's memory
Then i will have to put 3 note records, one for the prstatus, one for prpsinfo and one for the auxiliary vector.
This seems to be the right way as readelf gives me a similar output as what I got above with the real core dump.
Edit #2 : after getting the correct structure
I am now struggling with the different structures composing the note records.
Here is what I get when running a eu-readelf --notes on my core dump :
Note segment of 540 bytes at offset 0x74:
Owner Data size Type
CORE 336 PRSTATUS
CORE 136 PRPSINFO
CORE 8 AUXV
NULL
Here is what I get when running the same command on the real core dump :
Note segment of 488 bytes at offset 0xf4:
Owner Data size Type
CORE 144 PRSTATUS
info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
sigpend: <>
sighold: <>
pid: 28339, ppid: 41446, pgrp: 28339, sid: 41446
utime: 0.000000, stime: 0.000000, cutime: 0.000000, cstime: 0.000000
orig_eax: -1, fpvalid: 0
ebx: -1 ecx: 0 edx: 0
esi: 0 edi: 0 ebp: 0xffb9fcbc
eax: -1 eip: 0x08014b26 eflags: 0x00010286
esp: 0xffb9fcb4
ds: 0x002b es: 0x002b fs: 0x0000 gs: 0x0000 cs: 0x0023 ss: 0x002b
CORE 124 PRPSINFO
state: 0, sname: R, zomb: 0, nice: 0, flag: 0x00400400
uid: 9432, gid: 6246, pid: 28339, ppid: 41446, pgrp: 28339, sid: 41446
fname: pikeos_app, psargs: ./pikeos_app
CORE 160 AUXV
SYSINFO: 0xf7768420
SYSINFO_EHDR: 0xf7768000
HWCAP: 0xbfebfbff <fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe>
PAGESZ: 4096
CLKTCK: 100
PHDR: 0x8010034
PHENT: 32
PHNUM: 2
BASE: 0
FLAGS: 0
ENTRY: 0x80100be
UID: 9432
EUID: 9432
GID: 6246
EGID: 6246
SECURE: 0
RANDOM: 0xffb9ffab
EXECFN: 0xffba1feb
PLATFORM: 0xffb9ffbb
NULL
Does someone have any clue or explanations about why my note records are not read properly ? I thought it might be due to incorrect offsets, but then why would the records be correctly listed ?
Thanks !
Was having same troubles some time ago with my project of converting CRIU images into core dumps. It is fully written in python(even elf structures are in ctypes), so it could be used as a guide. See https://github.com/efiop/criu-coredump .I.e. how everything is structured could be seen here https://github.com/efiop/criu-coredump/blob/master/criu_coredump/core_dump.py .
这篇关于核心转储注释部分的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!