GEEP Presents

Linux Kernel
Debugging

Part I

Amit Kale

   
 Presentation Outline

●
Need for kernel debugging techniques
●
Basic debugging (printks)
●
Overview of KDB
●
Overview of KGDB
●
Living with KGDB limitations
●
Questions and answers!

   
 Need for special techniques

●
Bugs in kernel code being developed frequently 
result in a lockup or a reboot
●
It's difficult to locate the problem – entry points
●
Kernel debugging techniques help collect 
information
●
Logging, kernel problem state information and 
live debugging

   
 Kernel Debugging techniques

●
Logging
Printk, kernel logging frameworks
/proc interface
●
Dump kernel state (crash dump)
Registers, memory, threads
●
Live debugging
Kernel debuggers ­ KDB, KGDB

   
 Printks ­ Pros

●
Easy, printf like

●
Unlimited logging capabilities

●
Instantaneous via console

●
Can be used from most of the kernel code

   
 Printk ­ Example
●
Need to analyze orphan in­core inodes
●
Reproduction case available
●
Dump ino, hold count
on each inode hold and release
●
A simple mount, traverse / and unmount
●
Look at dmesg or /var/log/messages
●
Trace the inode using debugfs utility
●
Trace code for possible omission of a release
   
 Printk – OOPS
Unable to handle kernel NULL pointer dereference at virtual address 00000004
 printing eip:
c0289b74
*pde = 00000000
Oops: 0002 [#1]
PREEMPT SMP  Short Description
Modules linked in: appletalk psnap llc drbd bonding i2c_i801 i2c_dev i2c_core 
nls_cp437 aic7xxx e1000 e100 sym53c8xx
CPU:    0
EIP:    0060:[<c0289b74>]    Not tainted VLI
EFLAGS: 00010286   (2.6.10) 
EIP is at xfs_ail_insert+0x84/0xd0
eax: 00000000   ebx: ffffffff   ecx: fffffc19   edx: ffffffff Register dump
esi: c9d9bdfc   edi: d3164818   ebp: cd0631f4   esp: df653e00
ds: 007b   es: 007b   ss: 0068
Process xfslogd/0 (pid: 178, threadinfo=df652000 task=deef3520)
Stack: 00001d3c 00000002 00000000 00000000 cd0631f4 d3164818 d3164800 c7f5cdfc 
       c0289924 d3164818 cd0631f4 00000000 00001d3c 00000002 00000000 cd0631f4 
       00001d3c 00000002 c02894e8 d3164800 cd0631f4 00001d3c 00000002 00000000 
Call Trace:
 [<c0289924>] xfs_trans_update_ail+0x54/0xb0
 [<c02894e8>] xfs_trans_chunk_committed+0x158/0x1f0 Function call stack
 [<c02892cc>] xfs_trans_committed+0x3c/0x100
 [<c027cebe>] xlog_state_do_callback+0x20e/0x2c0
 [<c027cfc3>] xlog_state_done_syncing+0x53/0x70
 [<c027b967>] xlog_iodone+0x47/0xb0

   
 Printks ­ Cons

●
Slow
●
Useless for analyzing races and irqs
●
Requires code instrumentation – a compile­run 
cycle
●
Mistakes can result in kernel crashes
●
Can't be used to debug kernel panics and 
deadlocks

   
 /proc interface

●
Plenty of info exported via /proc
●
slabinfo – chunks available in each slab
●
interrupts – occurrence, CPU­balancing
●
ioports – io­range for device and driver
●
vmstat – virtual memory statistics, pages

   
 Live Debugging ­ KDB

●
Assembly level debugger
●
Accessible through console
●
Analysis of kernel state – registers, variables, 
stack traces
●
Live analysis – single step, breakpoints, threads
●
Requires understanding of instruction set
●
Difficult for newbies

   
 Live Debugging ­ KGDB

●
Source level debugger – gdb interface
●
Analysis of kernel state – registers, variables, 
stack traces
●
Live analysis – single step, breakpoints, threads
●
Easy for newbies
●
Requires two machines – Development and test 
(host and target)

   
 KGDB Structure (ethernet)

Test Machine

Development Machine
Ethernet
KGDB stub
Modified GDB
KGDB Ethernet interface
Kernel sources
Panic notification
Module sources
hooks

   
 KGDB Setup
Apply a kgdb patch Configure and Copy to
(Development machine) build kernel test machine

Run GDB Reboot the machine

Do kernel analysis Connect to KGDB Kgdb connects

Run test cases
   
 Debug kernel panics
Kernel panic
unhandled page fault

Write code KGDB takes control

Identify the reason
Null­pointer access Look at the backtrace

Look at the backtrace

   
 Module debugging
Module sources Copy to
Build with debug info
(Development machine) test machine

Tell module directory
Load the module
to gdb

Module debugging Gdb reads module
Module load complete
like base kernel object automatically

Run test cases
   
 KGDB – Living with optimizations

●
Kernel compiled with optimizations
●
Each C source line spread over instructions
●
Instruction ranges for lines overlap
●
Control may appear to go backward in gdb
●
Inline functions expand into large code
●
Variables local to inline functions not visible
●
Line numbers in inline funtions make life difficult

   
 KGDB – Living with optimizations
●
Disable some of the optimizations (man gcc)
●
Add ­fschedule­insns ­fschedule­insns2 to 
CFLAGS in Makefile and recompile all
●
Run objdump ­S on vmlinux or module.ko files 
to find _exact_ line numbers from instruction 
pointer
●
Caller function may provide better info – frame 1 
etc.