| Rev | Author | # | Line |
|---|---|---|---|
| 3 | AristotlePagaltzis | 1 | To debug a LinuxKernel, use <tt>objdump</tt> and look for the hex offset from the crash output to find the valid line of code/assembler. Without debug symbols, you will see the [Assembler] code for the routine shown, but if your [Kernel] has debug symbols the [C] code will also be available. (Debug symbols can be enabled in the kernel hacking menu of the menu configuration.) For example:'''' |
| 1 | IanMcDonald | 2 | |
| 3 | AristotlePagaltzis | 3 | <verbatim> |
| 4 | objdump -r -S -l --disassemble net/dccp/ipv4.o | ||
| 5 | </verbatim> | ||
| 6 | |||
| 7 | NB.: you need to be at the top level of the kernel tree for this to pick up your [C] files. | ||
| 4 | IanMcDonald | 8 | |
| 9 | The stack trace will have lines something like: | ||
| 10 | <verbatim> | ||
| 11 | dccp_sendmsg+0x135/0x17f | ||
| 12 | </verbatim> | ||
| 13 | The 0x135 is offset from the start of the function. The 0x17f is the total function length. The output from objdump shows byte in absolute format from start of file so you will need to add the offset to the start of the function and then you will find your line of code. | ||
| 1 | IanMcDonald | 14 | |
| 15 | If you don't have access to the code you can also debug on some crash dumps e.g. crash dump output as shown by Dave Miller. | ||
| 16 | |||
| 3 | AristotlePagaltzis | 17 | > <verbatim> |
| 18 | > EIP is at ip_queue_xmit+0x14/0x4c0 | ||
| 19 | > ... | ||
| 20 | > Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00 | ||
| 21 | > 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08 | ||
| 22 | > <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85 | ||
| 23 | > </verbatim> | ||
| 24 | > | ||
| 25 | > Put the bytes into a "<tt>foo.s</tt>" file like this: | ||
| 26 | > | ||
| 27 | > <verbatim> | ||
| 28 | > .text | ||
| 29 | > .globl foo | ||
| 30 | > foo: | ||
| 31 | > .byte .... /* bytes from Code: part of OOPS dump */ | ||
| 32 | > </verbatim> | ||
| 33 | > | ||
| 34 | > Compile it with "<tt>gcc -c -o foo.o foo.s</tt>" then look at the output of "<tt>objdump --disassemble foo.o</tt>". | ||
| 35 | > | ||
| 36 | > Output: | ||
| 37 | > | ||
| 38 | > <verbatim> | ||
| 39 | > ip_queue_xmit: | ||
| 40 | > push %ebp | ||
| 41 | > push %edi | ||
| 42 | > push %esi | ||
| 43 | > push %ebx | ||
| 44 | > sub $0xbc, %esp | ||
| 45 | > mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb) | ||
| 46 | > mov 0x8(%ebp), %ebx ! %ebx = skb->sk | ||
| 47 | > mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt | ||
| 48 | > </verbatim> | ||
| 1 | IanMcDonald | 49 | |
| 3 | AristotlePagaltzis | 50 | Another very useful option of the Kernel Hacking section in menuconfig is <tt>Debug memory allocations</tt>. This will help you see whether data has been initialised and not set before use etc. To see the values that get assigned with this look at <tt>mm/slab.c</tt> and search for <tt>POISON_INUSE</tt>. When using this an <tt>Oops</tt> will often show the poisoned data instead of zero which is the default. |
| 1 | IanMcDonald | 51 | |
| 3 | AristotlePagaltzis | 52 | ! See also: |
| 1 | IanMcDonald | 53 | |
| 3 | AristotlePagaltzis | 54 | * KernelDevelopment |
| 55 | * KernelDevelopmentWithGit | ||
| 1 | IanMcDonald | 56 | |
| 57 | ---- | ||
| 58 | CategoryKernel |
lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 2 times)