Kgdb principle Introduction and Kgdboe mode configuration of Linux kernel-driven development __linux

Http://www.linuxidc.com/Linux/2013-06/86406.htm

The first step of the Linux kernel-driven development kgdb (Kgdboc Way) http://www.linuxidc.com/Linux/2013-06/86233.htm is followed. In the previous article, only a simple introduction to the use of serial port KGBD process (Kgdboc way), this article will focus on the KGDB debugging Linux kernel principle. The linux,kgdb of the kernel version before 2.6.26 is installed through patches, and the process is very complex and more problematic. The Linux kernel is already integrated internally from the 2.6.26 kgdb, just configure the KGDB and recompile the 2.6.26 (or higher) kernel. The use of Kgdb debugging requires two machines, that is, the host and the target machine (generally for the Development Board), both through the serial line connected. The kernel compilation to be debugged needs to be configured to support KGBD, which runs on the target machine, and the host uses GDB to remotely debug the kernel on the target machine via a serial port. In addition, KGDB also support the network mode (that is, Kgdboe mode) for remote debugging kernel, see the third part of this article.

First, Kgdb principle:

KGDB related source code is mainly implemented on the host remote debugging required functions, including command processing, trap processing and serial communication 3 main parts. Kgdb adds a debug stub to the Linux kernel, a small piece of code in the Linux kernel, a medium between the developer running GDB and the target kernel. GDB communicates with the debug stub through the GDB serial protocol. The GDB serial protocol is a message based ASCII protocol that contains a variety of debugging commands. When a breakpoint is set, Kgdb replaces the breakpoint's instruction with a trap instruction, and the control is transferred to the debug stub when the breakpoint is executed. At this point, the task of debugging stub is to use the Remote Serial communication protocol to transfer the current kernel environment to GDB, and then receive commands from GDB. The GDB command tells the debugger what to do next, and when the stub receives the command that continues to execute, the kernel's operating environment is restored and the control over the CPU is returned to the kernel.

Second, kgdb Functional components:

(1) GDB stub.

The Gdb stub, known as a debug insert (stub), is the core of the Kgdb debugger. It is a small piece of code in the Linux kernel that handles the various requests from GDB on the host, and controls the processor on the target machine when the kernel is in the debug state.

(2) Trap handling.

When you set a breakpoint, KGDB provides an exception handler that replaces the command at the breakpoint location with an exception instruction. This exception occurs when the breakpoint is executed, and the kernel gives CPU control to the Kgdb debugger, and the program goes into the KGDB provided exception handling function. In the exception handler, you can analyze the various scenarios of the kernel code.

(3) Serial communication.

GDB communicates with the debug stub through the GDB serial protocol. It is a message based ASCII protocol that contains a variety of debugging commands.

Third, Kgdboe mode configuration: (see Linux kernel-driven development of the KGDB single Step debugging kernel (Kgdboc way))

The last thing to say is that in addition to the use of strings, you can also use the network card communication, that is, Kgdboe way. Kgdboe Way is superior to Kgdboc way, the last article Kgdboc use process also mentioned, when the U-boot load kernel executes to kgdb:waiting for connection to remote GDB ... To manually turn off the serial port, this serial port is also required for GDB to connect remotely. The effect is that we can't see the output of the kernel during debugging, and the NIC (Kgdboe) approach just avoids this flaw. The following is a brief introduction to the configuration process for the following network card mode (KGDBOE):

(1) Configure the kernel:

A) Config_netconsole (Networking Support-> network console logging support)

b) Config_debug_kernel (KERNEL hacking-> KERNEL debugging)

c) config_kgdb (Kernel hacking-> KGDB)

d) Config_kgdb_eth (Kernel hacking-> KGDB-> method of KGDB communication->)

(2) Modify the U-boot startup parameter Bootargs to support Kgdb debugging (similar to KGDBOC):

Setenv Bootargs ' Console=...kgdboe=[target-port]@<target-ip>/[dev][target-macaddr],[host-port]@

Example: kgdboe=@192.168.1.4/,@192.168.1.3/

Mainly add the above Red Font section, explain the meaning of the parameters:

Target-port (optional): GDB port (default 6443)
Target-ip:target IP address (i.e DVEVM IP address)
Dev (optional): Network interface (default eth0)
Host-port (optional): Host port use to Send/recieve UDP packets (default 6442)
Host-ip:host IP Address