core_dump

@Skyter:
嵌入式裝置的記憶體很小 (64MB or 128MB,但是 core dump 的大小卻很大,往往 do_coredump 做到 oom 卯起來砍。 我需要 do_coredump (in kernel) 與 gdb 能夠合作,只 dump 程式(/proc/<pid>/maps) 每一個 segment 16KBytes. 否則 do_coredump 因為前面 segments (.text and others) 塞爆 2048 blocks (ulimit -c 2048),導致後面的 threads stack segments 都沒有被記錄到 (end_coredump)。
這樣的結果導致 gdb bascktrace 分析 coredump (limited 2048) 只能倚靠 register(arm) : pc & lr 看到最底層導致錯誤的 function 與上一層,無法印出完整的 stack tree (因為缺少 stack segment) 。
真想建議 do_coredump 與 gdb 的作者合作改進 coredump 的功能。

@Scott:
有個省空間的作法是只取 stack trace:註冊 SIGSEGV handler,不跑 kernel core dump (do_coredump) 。就像 Android debuggerd 這樣:http://t2koba.blogspot.com/2011/05/debuggerd-of-android.html
從 debuggerd 裡面用 libunwind-ptrace 應可行。

@Skyter:
uclibc 不支援 backtrace => 放棄
http://stackoverflow.com/questions/2536021/any-porting-available-of-backtrace-for-uclibc
手工用 __builtin_return_address 來造 backtrace => 不支援 __builtin_return_address, 放棄
ptrace (GETREGS) 有意思 => debuggerd 衝進去 /proc/<pid>/maps 去讀 stack 記憶體並且解析它 => 很複雜(其實是不熟所以覺得複雜) => 暫時擱置吧。

等有空再來自己寫寫看。

其實我是有想過在 ld 設定 ELF LOAD 到後面一點的行程空間,然後 ptread_set_stack 把所有 pthread stack addr 調到開頭。這樣 core dump 就會先 dump pthreads stack, 卡在不熟悉 ld ,不知道該如何調整 LOAD 。 所以也是先擱置。
我剛學到,核心將執行檔載入記憶體後 (by ELF LOAD addr) ,會將控制權轉交給依照 PT_INTERP 所載明的 Dynamic Loader (ld-linux.so) 去載入其他 .so 。蠻好奇你想要改什麼 ?
http://www.cs.virginia.edu/~dww4s/articles/ld_linux.html
http://www.linuxjournal.com/article/6463?page=0,1
最近有翻過 Professional Linux Kernel Architecture 中文版附錄 E 說明 ELF 格式,還是有中文有差。… XD

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License