剛開通部落格，想寫部落格很久了，今天終於開通了。先把之前寫的學習筆記貼上來吧。
在程式執行出現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
0x1elf32
0x12's complement, little endian
0x11 (current)
unix - system v
e_type
elf型別，
et_core表示為core檔案
e_machine
0x28
elf檔案的平台屬性
e_version
e_entry
elf程式的入口虛擬位址
e_phoff
0x34
程式頭表的偏移，程式頭從0x34
開始，緊跟在
elf頭後面
e_shoff
e_flags
e_ehsize
0x34
elf檔案頭本身的大小，
52位元組
e_phentsize
0x20
每個程式頭占用的大小為32位元組
e_phnum
0xa1
程式頭表的個數，161個
e_shentsize
段描述符的大小
e_shnum
段描述符的個數
e_shstrndx
從上面資訊可知，core
檔案程式頭表從
0x34
位置開始，每個程式頭表的大小為
32位元組
下面看下core
檔案程式頭表的資訊
截圖只是程式頭表的部分資訊，因為有161
個程式頭表這裡無法全部顯示。
typedef struct elf32_phdr elf32_phdr;
分析下core
檔案中第乙個程式頭表的資訊，第乙個程式頭表的偏移是
上面**中是第乙個程式頭表的詳細資訊，分別用不同的顏色表明了不同的成員值。成員值
含義p_type
0x4段的型別，這裡為pt_note
p_offset
0x1454
段的位置相對於檔案開始的偏移
p_vaddr
段在記憶體中的首位元組位址
p_paddr
p_filesz
0x3904
段在檔案映像棧的位元組數
p_memsz
段在記憶體映像中的位元組數
p_flags
p_align
從上面的程式頭表資訊可知，第乙個段型別為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) 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
檔案。
gbd 分析core檔案 gdb core檔案除錯
core檔案在什麼位置建立 在 程序當前工作目錄的下建立。通常與程式在相同的路徑下。但如果程式中呼叫了chdir函式，則有可能改變了當前工作目錄。這時core檔案建立在 chdir指定的路徑下。有好多程式崩潰了，我們卻找不到core檔案放在什麼位置。和chdir函式就有關係。當然程式崩潰了不一定都產...
Linux之core檔案分析
當程式在執行的過程中異常終止或崩潰，作業系統會將程式當時的記憶體狀態記錄下來，儲存在乙個檔案中，這種行為就叫做core dump。我們可以認為 core dump 是 記憶體快照 但實際上，除了記憶體資訊之外，還有些關鍵的程式執行狀態也會同時 dump 下來，例如暫存器資訊 包括程式指標 棧指標等 ...
gdb 分析core檔案 小記
測試環境twemproxy程序突然出core退出，記錄一下gdb分析過程 解析 coredump檔案 bt 列印crash時的堆疊 gdb root proxy bin twemproxy tmp cordump.file gdb bt 0 0x00007f9f3b0d4337 in ssignal...