I'm trying to implement a function to backtrace a crashed user space process in kernel. Since, I'm working in Kernel, I don't have the luxury of any libraries and provided backtrace function doesn't support MIPS architecture. I'm just wondering if I can emulate what GDB does. The version of the kernel is 2.6.21.
views:
555answers:
2
+1
A:
The core file is in ELF format. This is a standard, which is available on many web site just one google away.
HOWEVER, this file format is non-trival. Lots of quirks and bits. Any reasonable person should use an 3rd party library. If you really want to do that, start with libelf and readelf. and wish yourself good luck.
J-16 SDiZ
2009-06-27 01:18:32
I just want to clarify. I'm not working with core files. I want to backtrace when user process crashes in kernel.
Quincy
2009-06-27 04:49:51
A:
I think you can reference the oprofile's implementation.
Oprofile use frame-pointer to get the back trace infomation, so it requires the user space applications and its related libraries all built with frame-pointer enabled.("-fno-omit-frame-pointer" option).
Another way is that if the user applications contains debug infomation, you may need check the user application's DWARF infomation, the DWARF call frame infomation proides the debugger with enough infomation about how a function called, so that it can locate each of the arguments to the function, locate the current call frame, and locate the call frame for the calling infomation.
If you want to simple crawl the back trace infomation without "frame-pointer" supported or any debug infomation, then you have to check the user application's mips instruction, loop through child's context(SP,IP,RP) things to get the parent context(SP,IP,RP) by the mips ABI specification, this is a little complicated and time consuming since you have to disassemble many instruction in the memory, but it works not bad. For example, for many routie, there is an "add sp, sp, -32" like instruction at the begging, and you will know that the parent'sp is current sp plus 32.
The second and third way you have to implement it yourself since you work in kernel.
arsane
2009-06-27 03:02:43
Actually, I have done some research on your third option. Let's say the stack is unwinded, how should one print out the function names, since we would only have memory address of the function?
Quincy
2009-06-27 05:11:02
@Quincy: parse the elf file of the user application, and you will get its symbol table. But if you want parse the elf in kernel, as the binary may just partly loaded to physical memory, you may involve page fault handling which may load/swap memory things, if on a coredump situation, this may fail. Or you can try load the symbol table at the program is loading for start
arsane
2009-06-27 06:01:59
@Quincy: for the third way, I know some work done for MIPS crawling with addresses and sent to user application which parse the related binary end show up call trace of symbol, but for show it in kernel's printk style, I have not seen.
arsane
2009-06-27 06:10:06