Differences between version 3 and revision by previous author of KernelDevelopmentDebugging.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 3 | Last edited on Wednesday, October 19, 2005 7:35:08 pm | by AristotlePagaltzis | Revert |
| Older page: | version 2 | Last edited on Tuesday, October 18, 2005 10:04:53 am | by IanMcDonald | Revert |
@@ -1,44 +1,52 @@
-To debug a kernel crash you can
use objdump to show
the assembler for the routine shown and
if debug symbols from kernel hacking menu are turned on then you can see
the C code also. There will
be a hex offset
in the crash output and just use that to find the valid line
of code/assembler
. For example:
-<tt>
-objdump -r -S -l --disassemble net/dccp/ipv4.o
-</tt>
+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:''''
-NB. You
need to be at the top level of the kernel tree for this to pick up your C files.
+ <verbatim>
+ objdump -r -S -l --disassemble net/dccp/ipv4.o
+ </verbatim>
+
+
NB.: you
need to be at the top level of the kernel tree for this to pick up your [
C]
files.
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.
-<verbatim>
-EIP is at ip_queue_xmit+0x14/0x4c0
- ...
-Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
-00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
-<8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
-
-Put the bytes into a "foo.s" file like this:
-
- .text
- .globl foo
-foo:
- .byte .... /* bytes from Code: part of OOPS dump */
-Compile it with "gcc -c -o foo.o foo.s" then look at the output
-
+> <verbatim>
+> EIP is at ip_queue_xmit+0x14/0x4c0
+> ...
+> Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
+> 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
+> <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
+> </verbatim>
+>
+> Put the bytes into a "<tt>foo.s</tt>" file like this:
+>
+> <verbatim>
+> .text
+> .globl foo
+> foo:
+> .byte .... /* bytes from Code: part of OOPS dump */
+> </verbatim>
+>
+>
Compile it with "<tt>
gcc -c -o foo.o foo.s</tt>
" then look at the output of "<tt>
objdump --disassemble foo.o</tt>
".
+>
+> Output:
+>
+> <verbatim>
+> ip_queue_xmit:
+> push %ebp
+> push %edi
+> push %esi
+> push %ebx
+> sub $0xbc, %esp
+> mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
+> mov 0x8(%ebp), %ebx ! %ebx = skb->sk
+> mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
+> </verbatim>
-Output:
+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.
-ip_queue_xmit
:
- push %ebp
- push %edi
- push %esi
- push %ebx
- sub $0xbc, %esp
- mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
- mov 0x8(%ebp), %ebx ! %ebx = skb->sk
- mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
-</verbatim>
+! See also
:
-Also a very useful menu option for menuconfig under Kernel Hacking is debug memory allocations as that 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 mm/slab.c and search for POISON_INUSE. When using this an Oops will often show the poisoned data instead of zero which is the default.
+* KernelDevelopment
+* KernelDevelopmentWithGit
-----
-See also KernelDevelopment
----
CategoryKernel
