core文件分析

刚开通博客，想写博客很久了，今天终于开通了。先把之前写的学习笔记贴上来吧。

在程序运行出现segmentfault后，我们会通过gdb来调试core文件定位问题，下面我们来分析下core文件是什么？

首先需要明确的一点就是core文件也是ELF格式的，ELF的格式如下：

 

ELF文件参与程序的链接和运行，从链接的角度看有上面左边所示的Linking View,从程序运行的角度看为右边所示的Execution View（执行视图）。Core的ELF文件格式是按照执行视图的格式组织的。

下面是core文件的ELF头信息

以内核代码elf_core_dump函数为入口分析core文件怎么生成的：

elf_core_dump-àfill_note_info-àfill_elf_header

static void fill_elf_header(struct elfhdr *elf, int segs,

    u16 machine, u32 flags, u8 osabi)

{

memset(elf, 0, sizeof(*elf));

 

memcpy(elf->e_ident, ELFMAG, SELFMAG);

elf->e_ident[EI_CLASS] = ELF_CLASS;

elf->e_ident[EI_DATA] = ELF_DATA;

elf->e_ident[EI_VERSION] = EV_CURRENT;

elf->e_ident[EI_OSABI] = ELF_OSABI;

 

elf->e_type = ET_CORE;

elf->e_machine = machine;

elf->e_version = EV_CURRENT;

elf->e_phoff = sizeof(struct elfhdr);

elf->e_flags = flags;

elf->e_ehsize = sizeof(struct elfhdr);

elf->e_phentsize = sizeof(struct elf_phdr);

elf->e_phnum = segs;

 

return;

这里填入的ELF头信息就是用readelf –h读取到的。下面我们看下生成的core文件

、

上面表格中是core文件的ELF头的详细信息，分别用不同的颜色表明了不同的成员值。

成员

值

含义

e_ident

"\177ELF"

magic

0x1

ELF32

0x1

2's complement, little endian

0x1

1 (current)

0

UNIX - System V

0

 

e_type

4

ELF类型，ET_CORE表示为core文件

e_machine

0x28

ELF文件的平台属性

e_version

1

 

e_entry

0

ELF程序的入口虚拟地址

e_phoff

0x34

程序头表的偏移，程序头从0x34开始，紧跟在ELF头后面

e_shoff

0

 

e_flags

0

 

e_ehsize

0x34

ELF文件头本身的大小，52字节

e_phentsize

0x20

每个程序头占用的大小为32字节

e_phnum

0xa1

程序头表的个数，161个

e_shentsize

0

段描述符的大小

e_shnum

0

段描述符的个数

e_shstrndx

0

从上面信息可知，core文件程序头表从0x34位置开始，每个程序头表的大小为32字节

下面看下core文件程序头表的信息

截图只是程序头表的部分信息，因为有161个程序头表这里无法全部显示。

typedef struct elf32_phdr{

  Elf32_Word p_type;

  Elf32_Off p_offset;

  Elf32_Addr p_vaddr;

  Elf32_Addr p_paddr;

  Elf32_Word p_filesz;

  Elf32_Word p_memsz;

  Elf32_Word p_flags;

  Elf32_Word p_align;

} Elf32_Phdr;

分析下core文件中第一个程序头表的信息，第一个程序头表的偏移是0x34

上面表格中是第一个程序头表的详细信息，分别用不同的颜色表明了不同的成员值。

成员

值

含义

p_type

0x4

段的类型，这里为PT_NOTE

p_offset

0x1454

段的位置相对于文件开始的偏移

p_vaddr

0

段在内存中的首字节地址

p_paddr

0

 

p_filesz

0x3904

段在文件映像栈的字节数

p_memsz

0

段在内存映像中的字节数

p_flags

0

 

p_align

0

从上面的程序头表信息可知，第一个段类型为NOTE段，偏移为0x1454，大小为0x3904。

PT_NOTE类型的段用于存放线程信息和寄存器信息。由于PT_NOTE段是辅助信息，不存在与内存中。

那么PT_NOTE段信息是怎么存储的呢？

去内核中看下相应代码fill_note_info函数

fill_note_info函数代码片段：

       //首先将所有的线程加入到info-> thread_list

for (ct = current->mm->core_state->dumper.next;

ct; ct = ct->next) {

ets = kzalloc(sizeof(*ets), GFP_KERNEL);

if (!ets)

return 0;

 

ets->thread = ct->task;

list_add(&ets->list, &info->thread_list);

}

        //遍历链表，调用elf_dump_thread_status保存线程的信息

list_for_each(t, &info->thread_list) {

int sz;

 

ets = list_entry(t, struct elf_thread_status, list);

sz = elf_dump_thread_status(signr, ets);

info->thread_status_size += sz;

}

接着分析elf_dump_thread_status函数

elf_dump_thread_status函数代码：

static int elf_dump_thread_status(long signr, struct elf_thread_status *t)

{

int sz = 0;

struct task_struct *p = t->thread;

t->num_notes = 0;

 

fill_prstatus(&t->prstatus, p, signr); //获取线程的状态，包括signal和pid等

elf_core_copy_task_regs(p, &t->prstatus.pr_reg);  //获取线程的寄存器信息

fill_note(&t->notes[0], "CORE", NT_PRSTATUS, sizeof(t->prstatus),

  &(t->prstatus)); //将信息存入memelfnote的notes数组中

t->num_notes++;

sz += notesize(&t->notes[0]);

…

return sz;

}

上面就是填充PT_NOTE段的主要代码流程，回过头来我们看下PT_NOTE段的数据结构：

/* Note header in a PT_NOTE section */

typedef struct elf32_note {

  Elf32_Word n_namesz; /* Name size */

  Elf32_Word n_descsz; /* Content size */

  Elf32_Word n_type; /* Content type */

} Elf32_Nhdr;

 

struct elf_note_info {

struct memelfnote *notes;

struct elf_prstatus *prstatus; /* NT_PRSTATUS */

struct elf_prpsinfo *psinfo; /* NT_PRPSINFO */

struct list_head thread_list;

elf_fpregset_t *fpu;

int thread_status_size;

int numnote;

};

下面分析core文件的PT_NOTE段信息：

上面的寄存器信息正好与gdb看到的寄存器信息一致

上面只是分析了PT_NOTE段的一部分，我们定位coredump的问题也不需要这样脑神费力的分析二进制core文件。