Debugging The Linux Kernel Using Gdb - Revision history

Jsujjava: Add Category Development Tools

2011-05-09T14:30:58Z

Add Category Development Tools

Peter Huewe: moved DebuggingTheLinuxKernelUsingGdb to Debugging The Linux Kernel Using Gdb: We can use spaces even in the title; )

2011-04-13T21:58:49Z

moved DebuggingTheLinuxKernelUsingGdb to Debugging The Linux Kernel Using Gdb: We can use spaces even in the title; )

Keesj: /* Loading Symbols of a loaded module */

2009-01-05T13:22:24Z

‎Loading Symbols of a loaded module

Dirk: Add some links, fix some typos and minor formatting

2008-12-16T06:11:01Z

Add some links, fix some typos and minor formatting

Keesj: Added links/pointers to in kernel documentation

2008-12-15T21:11:25Z

Added links/pointers to in kernel documentation

Keesj: /* Loading the files */

2008-12-09T20:22:08Z

‎Loading the files

Keesj: /* loading the files */

2008-12-09T11:17:49Z

‎loading the files

Keesj: /* Debugging the linux kernel using gdb */

2008-12-08T07:18:15Z

‎Debugging the linux kernel using gdb

Keesj: /* Debugging the kernel */

2008-12-07T12:43:26Z

‎Debugging the kernel

Keesj: /* Debugging the linux kernel using gdb */

2008-12-06T10:16:07Z

‎Debugging the linux kernel using gdb

← Older revision		Revision as of 14:30, 9 May 2011
Line 159:		Line 159:

	A "find . -name "gdb" in the linux kernel directory also shows up a few interesting .gdbinit files that apparently can perform low level initialization.		A "find . -name "gdb" in the linux kernel directory also shows up a few interesting .gdbinit files that apparently can perform low level initialization.
		+	[[Category:Development Tools]]

@@ Line 143: / Line 143: @@
   add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000
-Note that we use the .o file and not the .ko one. The address at the end is currently gotten from running.
+Note that we use the .o file and not the .ko one. The address at the end is the address where the kernel decided to load
 == Pointers ==

@@ Line 1: / Line 1: @@
 = Debugging the linux kernel using gdb =
-The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.
+The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]]. Using printk is a relatively simple, effective and cheap way to find problems. There are many other Linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the GNU debugger (GDB) to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.
-Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!
+Most of the examples here will work in two (open source) situations. When using [[JTAG|JTAG]] and when using [[Qemu|QEMU]] system emulation. As the second option does not require any hardware you could go on and try it right away!
-The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9
+The open source JTAG debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. [http://openocd.berlios.de/web/ OpenOCD] is pretty usable on the targets we tested ARM11 and ARM9.
 == Requirements ==
 GDB:
-You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.
+You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target (read armv6). with that you might also want to have the gdbserver that can serve as stub for you user land debugging.
 OpenOCD:
-TODO..
+TODO...
 A JTAG Dongle:
 TODO...
 == The basics ==
@@ Line 26: / Line 24: @@
 To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done
-you can do your normal kernel development. When needed you can "hook-up" your debugger
+you can do your normal kernel development. When needed you can "hook-up" your debugger. Start debugging a running kernel.
 Start debugging a running kernel.
 - start openocd
 === vmlinuz v.s zImage ===
-When you want to debug the kernel you need a little understanding of how the kernel is composed.
+When you want to debug the kernel you need a little understanding of how the kernel is composed. Most important is the difference between your vmlinux and the zImage. What you need to understand at this point is that the zImage is a container. This container gets loaded by a boot loader and that execution is handed over to the zImage. This zImage unpacks the kernel to the same memory location and starts executing the kernel. (explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot
 Most important is the difference between your vmlinux and the zImage. What you need to understand at this point
-is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage.
 This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot
   vmlinux
@@ Line 41: / Line 35: @@
   `-- zImage
-vmlinux is what we will be using during debugging of the linux kernel.
+vmlinux is what we will be using during debugging of the Linux kernel.
 === Debugging the kernel ===
-The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't
+The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't need to modify the kernel in any way. This is because we operate on the hardware, CPU core level. Overall this means that you can follow your normal development method. You can let your bootstrap and boot loader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be as simple as loading the vmlinuz and connecting to the remote target:
-need to modify the kernel in any way. This is because we operate on the hardware , cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the vmlinuz and connecting to the remote target
   load vmlinuz
@@ Line 53: / Line 46: @@
 === Loading a kernel in memory ===
-Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels
+Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel and reset your board using the JTAG reset signal. Your boot loader will initialize your board and the execution will stop at the start of the kernel. After that you can load a kernel into memory and run it.
 onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel
-and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.
-after that you can load a kernel into memory and run it.
-execute the following:
+Execute the following:
   (gdb) file vmlinux
@@ Line 82: / Line 72: @@
   (gdb) cont
-This will boot your kernel that was loaded into memory via jtag
+This will boot your kernel that was loaded into memory via JTAG.
 === Getting the kernel log buffer ===
-Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.
+Sometimes the kernel will panic before the serial is up and running. In such situations is it '''very''' handy to be able to dump the kernel log buffer. This can be done by looking at the content of the __log_buf in the kernel. In gdb this can be done by issuing
-this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing
   p (char*) &__log_buf[log_start]
@@ Line 93: / Line 82: @@
 There must be a simple way of printing the memory area between log_start and log_end.
-The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.
+The problem is that gdb stops after the first line. Currently we use this routine that copied from wchar.gdb until something "normal" came out. We defined dmesg it like this:
-we defined dmesg it like this:
   define dmesg
@@ Line 120: / Line 108: @@
 ==Determining the module load address ==
-gdb itself does not have knowledge about kernel modules and when debugging
+gdb itself does not have knowledge about kernel modules and when debugging a kernel module. We will need to help gdb a little. One problem with modules is that it is not possible to determine where in the memory a module will be loaded before it is actually loaded so only once it is loaded we need to determine the address in memory it is loaded and tell gdb about it. There are many ways of determining this information. Here are 3 ways:
 a kernel module. We will need to help gdb a little. One problem with modules
 is that it is not possible to determine where in the memory a module
-will be loaded before is actually is loaded so only once is it loaded we need
 to determine the address in memory it is loaded and tell gdb about it.
-There are many ways of determining this information. I will list 3 ways
   lsmod
@@ Line 158: / Line 141: @@
 ==Loading Symbols of a loaded module ==
-add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000
+Note that we use the .o file and not the .ko one. The address at the end is currently gotten from running.
-note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running
-−
 == Pointers ==
@@ Line 175: / Line 157: @@
-A "find . -name "*gdb*" in the linux kernel directory also shows up a few interesting dotgdbinit files
+A "find . -name "*gdb*" in the linux kernel directory also shows up a few interesting .gdbinit files that apparently can perform low level initialization.
 that apparently can perform low level initialization.

← Older revision		Revision as of 21:11, 15 December 2008
Line 161:		Line 161:
	add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000		add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000
	note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running		note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running
		+
		+
		+	== Pointers ==
		+
		+	In the Linux Documentation directory under the kdump you will find file called gdbmacros.txt and it looks very promising as among other things it contains the a dmesg implementation
		+
		+	head linux-2.6.22.1/Documentation/kdump/gdbmacros.txt
		+	#
		+	# This file contains a few gdb macros (user defined commands) to extract
		+	# useful information from kernel crashdump (kdump) like stack traces of
		+	# all the processes or a particular process and trapinfo.
		+	#
		+
		+
		+	A "find . -name "gdb" in the linux kernel directory also shows up a few interesting dotgdbinit files
		+	that apparently can perform low level initialization.

@@ Line 156: / Line 156: @@
   end
-==Loading the files ==
+==Loading Symbols of a loaded module ==
 add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000
 note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running

← Older revision		Revision as of 10:16, 6 December 2008
Line 6:		Line 6:

	The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9		The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9
		+
		+	== Requirements ==
		+	GDB:
		+
		+	You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.
		+
		+	OpenOCD:
		+
		+	TODO..
		+
		+	A JTAG Dongle:
		+
		+	TODO...
		+
		+

	== The basics ==		== The basics ==