Debugging Linux Kernel using KGDB Part 1

-
What is KGDB?

KGDB Stands for Kernel GDB.

User space programs can be debugged remotely using the combination of gdbserver on the target machine and gdb on the host machine/development machine. But you cannot use the same setup for debugging kernel, as gdbserver is still running as a user space application on the kernel which we want to debug. To solve this program, KGDB comes into picture. KGDB acts as a gdbserver inside the server.

Typical Setup

A typical KGDB setup requires two machines connected by serial cable.
  • Host/Development Machine: Runs gdb and performs debugging
  • Target Machine: Runs kgdb and is the machine to be debugged


Test Setup

Setup on Target VM:

1.    Build and install the latest Linux kernel on the target VM machine, make sure you add the following kernel configurations. Follow this link to build if you are beginner. https://embeddedguruji.blogspot.com/2018/12/steps-to-build-and-install-latest-kernel.html




CONFIG_KGDB
CONFIG_KGDB_SERIAL_CONSOLE


2.   Copy the vmlinux image from this target VM to the development VM
3. Establish Serial Communication between two Virtual Machines using the following documentation: https://embeddedguruji.blogspot.com/2018/12/connecting-serial-ports-of-two-ubuntu.html

4.  Append the following command -line to kernel command line in grub
kgdbwait kgdboc=ttyS1,115200 sysrq_always_enabled
kgdbdoc tells the kernel to use ttyS1 serial port and 115200 baud rate
kgdwait tells the kernel to wait until the debugger is attached
sysrq_always_enabled enabling the sysrq 


You can follow the following documentation, if you are beginner:


5. Reboot the machine and you will observe that the target VM is freezed after grub bootloader stage.



Setup on Host/Development Machine 

1. Run the following commands:
  • gdb vmlinux
  • target remote /dev/ttyS1
  • continue


Note: It is better to copy the whole linux build folder instead of just vmlinux to get source level debugging



Comments

Post a Comment

Popular posts from this blog

bb.utils.contains yocto

-
Image
bb.utils.contains  is most commonly used function in Yocto. grep in poky directory returned with 696 count. $ grep -nr 'bb.utils.contains' poky/ | wc -l 696 It's definition is present in 'poky/bitbake/lib/bb/utils.py' file This function returns third argument if the second argument is subset of the first argument else returns fourth argument Let's take an example to understand this. You can see from the above screenshot, when the second argument is a subset of first argument, "present" was returned, else "notpresent" was returned We can also use bb.utils.contains inside if loop. This we can use inside a recipe. if ${@bb.utils.contains('SOMEFLAG','NEWVALUE3','true','false',d)}; then     FOO = 'HELLO' fi
Read more

Difference between RDEPENDS and DEPENDS in Yocto

-
We normally observe these two (RDEPENDS and DEPENDS) whenever we open any recipe. What should we choose when we write our own recipe. DEPENDS -> Build Time Dependency RDEPENDS -> Run Time Dependency DEPENDS: When a recipe 'A' is DEPENDS on recipe 'B'. In this case, Bitbake first builds recipe 'B' and then recipe 'A' E.g. You need 'dbus' to be built before 'wpa_supplicant'. RDEPENDS: When a recipe 'A' is RDEPENDS on recipe 'B'. In this case, Bitbake deploys 'B' on the target system when it deploys 'A'.  E.g. 'perf' RDEPENDS on 'bash' In other words, DEPENDS are those set of packages that should be available while building package, whereas RDEPENDS are set of packages that should be available during execution of the program.
Read more

PR, PN and PV Variable in Yocto

-
PN : Represents the name of the recipe. The name is usually extracted from the recipe file name. PR:  Represents the revision of the recipe. Default value for this revision is "r0". Subsequent revisions of the recipe conventionally will have "r1", "r2" and so on. PV:  Represents the version of the recipe. Normally extracted from the recipe file name. For example: ffmpeg_3.4.2.bb recipe. ${PN} : ffmpeg ${PV} : 3.4.2
Read more