Use kgdb to debug Linux kernel and Kernel Modules

Use kgdb to debug Linux kernel and Kernel Modules

Created:
Article attributes: original
Article submission: xcspy (xcspy.com _ at_gmail.com)

Author: xcspy member ladybug
E-mail: xcspy.com@gmail.com
Home: www.xcspy.com

1. Comparison of several kernel debugging tools

KDB: Debugging can only be performed at the compilation code level;
The advantage is that two machines are not required for debugging.

GDB: it lacks some essential functions when debugging the module. It can be used to view the running status of the kernel, including in the disassembly.
Core Function.

Kgdb: It is very convenient to debug the kernel at the source code level. The disadvantage is that kgdb can only perform remote debugging, and it requires a string
Port line and two machines to debug the kernel (or run two operating systems on the same host using VMware software for debugging)
)

The method for using KDB and GDB to debug the kernel is relatively simple. Here we only describe how to use kgdb to debug the kernel.

2. Software and Hardware preparation

Environment:
One Developer (192.168.16.5 COM1) and one testing machine target (192.168.16.30 com2)
Pre-installed RedHat 9; A Serial Line

Download the following software package:
Linux Kernel 2.4.23 linux-2.4.23.tar.bz2
Kgdb kernel patch 1.9 linux-2.4.23-kgdb-1.9.patch
GDB gdbmod-1.9.bz2 for debuggable Kernel Modules

3. OK, start

3.1 testing string line
After the serial port is physically connected, run the following command for testing. stty can set the serial port parameters.

Run the following command on Developer:
Stty ispeed 115200 ospeed 115200-F/dev/ttys0
Echo Hello>/dev/ttys0
Run the following command on target:
Stty ispeed 115200 ospeed 115200-F/dev/ttys1
CAT/dev/ttys1

If there is no problem with the serial line, it will display hello on the target screen.

3.2 installation and configuration

3.2.1 Installation

Download linux-2.4.23.tar.bz2,linux-2.4.23-kgdb-1.9.patch,gdbmod-1.9.bz2 to developer
/Home/liangjian directory

* On the developer Machine

# Cd/home/liangjian
# Bunzip2 linux-2.4.23.tar.bz2
# Tar-xvf linux-2.4.23.tar
# Bunzip2 gdbmod-1.9.bz2
# Cp gdbmod-1.9/usr/local/bin
# Cd linux-2.4.23
# Patch-P1 <../linux-2.4.23-kgdb-1.9.patch
# Make menuconfig

Compile the following three items into the kernel in the kernel hacking configuration item
Kgdb: Remote (Serial) kernel debugging with GDB
Kgdb: thread Analysis
Kgdb: console messages through GDB

Note that you must add the-G option when compiling the kernel.
# Make Dep; Make bzimage

Use SCP to copy related files to target (other network tools can also be used)
# Scp arch/i386/boot/bzimage root@192.168.16.30:/boot/vmlinuz-2.4.23-kgdb
# SCP system. Map root@192.168.16.30:/boot/system. map-2.4.23-kgdb
# Scp arch/i386/kernel/gdbstart root@192.168.16.30:/sbin
Gdbstart is a tool provided by kgdb to activate the kernel hook and make the kernel in the debugging status.

3.2.2 Configuration

* On the developer Machine

Edit a file. gdbinit in the kernel source code directory (this file is used to initialize GDB). The content is as follows:
# Vi. gdbinit
Define RMT
Set remotebaud 115200
Target remote/dev/ttys0
End
#
The preceding macro RMT is defined in. gdbinit, which mainly sets the serial port number and speed used.

* On the target machine

Edit the/etc/grub. conf file and add the following lines:
# Vi/etc/grub. conf
Title Red Hat Linux (2.4.23-kgdb)
Root (hd0, 0)
Kernel/boot/vmlinuz-2.4.23-kgdb Ro root =/dev/hda1
#

Create a script file debugkernel in the root directory. The content is as follows:
# Vi debug
#! /Bin/bash
Gdbstart-s 115200-T/dev/ttys1 <EOF

EOF
# Chmod + x debugkernel
This script is mainly used to call the gdbstart program to set the serial port used on the target machine and its speed, and make the kernel in debugging
Status

3.3 start debugging

When the kernel or kernel module on the target is in the debugging status, you can view its variables, set breakpoints, view stacks, and so on.
Source code-level debugging is the same as debugging user programs with GDB.

3.3.1 debugging after kernel startup

* On the target machine

Restart the system. Choose 2.4.23-kgdb to start the kernel. After the kernel is started, run debugkenel,
The kernel stops running, displays information on the console screen, and waits for
Serial port connection

#./Debug
About to activate GDB stub in the kernel on/dev/ttys1
Waiting for connection from remote GDB...

* On the developer Machine

# Cd/home/liangjian/linux-2.4.23
# GDB vmlinux
Gnu gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
Welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu "...

Execute RMT macro
(GDB) RMT
Breakpoint () at kgdbstub. C: 1005
1005 atomic_set (& kgdb_setting_breakpoint, 0 );

At this time, the kernel on the target is in the debugging status. You can view its variables, set breakpoints, view stacks, and use GDB for debugging.
Same as user programs

View stacks
(GDB) BT
#0 breakpoint () at kgdbstub. C: 1005
#1 0xc0387f48 in init_task_union ()
#2 0xc01bc867 in gdb_interrupt (IRQ = 3, dev_id = 0x0, regs = 0xc0387f98)
Gdbserial. C: 158.
#3 0xc01_37b in handle_irq_event (IRQ = 3, regs = 0xc0387f98, Action = 0xce5a9860)
At IRQ. C: 452
#4 0xc0109597 in do_irq (regs =
{EBX =-1072671776, ECx =-1, EDX =-1070047232, ESI =-1070047232, EDI
=-1070047232, EBP =-1070039092, eax = 0, xds
=-1070071784, xes =-1070071784, orig_eax =-253, EIP =-1072671729, XCS =
16, eflags = 582, esp =-1070039072, XSS =-1072671582}) at IRQ. C: 639
#5 0xc010c0e8 in call_do_irq ()

View the value of the jiffies variable
(GDB) P jiffies
$1 = 76153

If you want the kernel on the target to continue running, execute the continue command.
(GDB) continue
Continuing.

3.3.2 kernel debugging during boot

Kgdb can be debugged during kernel boot, but not all boot processes are debuggable, for example, in kgdb 1
In version 9, it inserts the following code in the start_kernel () function of init/Main. C:
Start_kernel ()
{
......
Smp_init ();
# Ifdef config_kgdb
If (gdb_enter ){
Gdb_hook ();/* right at boot time */
}
# Endif
......
}

Therefore, the initialization boot process before smp_init () cannot be debugged.

In addition, to make the target kernel in the debugging status during boot, you need to modify the/etc/grub. conf file as follows:
Form:
Title Red Hat Linux (2.4.23-kgdb)
Root (hd0, 0)
Kernel/boot/vmlinuz-2.4.23-kgdb Ro root =/dev/hda1 GDB gdbttys = 1 gdbbaud = 115
200

* On the target machine

Boot The 2.4.23-kgdb kernel. The kernel will be paused and enter the debugging status after a short run. The following information is printed:
Waiting for connection from remote GDB...

* On the developer Machine

# Cd/home/liangjian/linux-2.4.23
# GDB vmlinux
Gnu gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
Welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu "...

Execute RMT macro
(GDB) RMT
Breakpoint () at kgdbstub. C: 1005
1005 atomic_set (& kgdb_setting_breakpoint, 0 );

View Current Stack
(GDB) BT
#0 breakpoint () at kgdbstub. C: 1005
#1 0xc0387fe0 in init_task_union ()
#2 0xc01bc984 in gdb_hook () at gdbserial. C: 250
#3 0xc0388898 in start_kernel () at init/Main. C: 443

Set a breakpoint in the do_basic_setup function and restore the kernel.
(GDB) B do_basic_setup
Breakpoint 1 at 0xc0388913: file current. H, line 9.
(GDB) continue
Continuing.
[New thread 1]
[Switching to thread 1]

Breakpoint 1, do_basic_setup () at current. h: 9
9 _ ASM _ ("andl % ESP, % 0;": "= r" (current): "0 "(~ 8191ul ));

View the current stack after the kernel stops running at the do_basic_setup breakpoint
(GDB) BT
#0 do_basic_setup () at current. h: 9
(GDB)

3.3.3 kernel module debugging

To debug the kernel module, corresponding GDB support is required. The kgdb homepage provides a tool gdbmod, which fixes
DB 6.0 errors when parsing module addresses can be used to correctly debug Kernel Modules

* On the developer Machine

The kernel module orig for testing is written as follows:
Void xcspy_func ()
{
Printk ("<1> xcspy_func/N ");
Printk ("<1> aaaaaaaaaaa/N ");
}

Int xcspy_init ()
{
Printk ("<1> xcspy_init_module/N ");

Return 0;
}

Void xcspy_exit ()
{
Printk ("<1> xcspy_cleanup_module/N ");
}

Module_init (xcspy_init );
Module_exit (xcspy_exit );

Compile this module:
# Cd/home/liangjian/lkm
# Gcc-d1_kernel _-dmodule-I/home/liangjian/linux-2.4.23/include-o-wall-g-C
-O orig. O orig. c
# SCP orig. O root@192.168.16.30:/root

Start debugging:
# Gdbmod vmlinux
Gnu gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
Welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu "...

Set the search path for the symbol File
(GDB) set solib-search-path/home/liangjian/lkm

Execute RMT macro
(GDB) RMT
Breakpoint () at kgdbstub. C: 1005
1005 atomic_set (& kgdb_setting_breakpoint, 0 );

Set the breakpoint so that you can debug the init function of the kernel module. Check the kernel source code to see that the kernel uses the module. c file
Line 3 (sys_init_module function) mod-> init to call the module's init Function
(GDB) B module. C: 566
Breakpoint 1 at 0xc011cd83: file module. C, line 566.
(GDB) c
Continuing.
[New thread 1352]
[Switching to thread 1352]

At this time, execute insmod orig. O on the target machine, and the developer will be suspended at the breakpoint, as shown below:


Breakpoint 1, sys_init_module (name_user = 0xc03401bc "/001 ",
Mod_user = 0x80904d8) at module. C: 566
566 if (mod-> init & (error = mod-> Init ())! = 0 ){

Use the step command to enter the module's init Function
(GDB) Step
Xcspy_init () at orig. C: 12
12 printk ("<1> xcspy_init_module/N ");
(GDB) N
15}
(GDB)

Note:
It is relatively simple to debug the non-init function of the kernel module. You only need to execute insmod orig. O on the target.
The module symbol is loaded. You can directly set a breakpoint for the module function you want to debug In the developer's GDB, such as bt xcs.
Py_func. Later, when xcspy_func is called, it enters the debugging status.
To debug the init function of the kernel module, you cannot directly
It is relatively difficult to set breakpoints for the module's init function. Two workarounds can be used: 1.
Insert a breakpoint somewhere before the init function of the kernel call module is called, such as BT sys_init_modu.
Le () or BT module. C: 566; 2. Run the in
Smod orig. O, at this time, the orig. O symbol has been loaded into the memory, you can directly in the developer's GDB Module
The init function of sets the breakpoint, such as BT xcspy_init, and then rmmod orig. O on the target.
The debugging status is displayed when orig. O is reloaded. The developer is paused at xcspy_init.